Default methods - Revision history

JaroslavTulach: Redirecting to DefaultMethods

JaroslavTulach — Mon, 05 Mar 2018 10:38:06 GMT

←Older revision		Revision as of 10:38, 5 March 2018
Line 1:		Line 1:
-	~~An ability to add ('''default''') implementation for~~ [[~~Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]].~~	+	#REDIRECT [[DefaultMethods]]
-		+
-	~~== Useful? ==~~	+
-		+
-	From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe - e.g. use it as [[ProviderAPI]].	+
-		+
-	Later one needs to add new methods into the [[ClientAPI]] side of the contract. In such situation one is going to welcome [[default methods]] as a nice way to help one get ''out of the corner''. By adding [[default methods]] one can enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''.	+
-		+
-	~~However the concept of [[default methods]] also comes with drawbacks.~~	+
-		+
-	~~== Increasing Fuzziness ==~~	+
-		+
-	However '''interface''' with [[default methods]] is [[clarity\|fuzzier]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.	+
-		+
-	When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases [[fuzziness]]. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.	+
-		+
-	Envision a pure '''interface''' defined in an initial version. Imagine the interface being implemented by various parties [[API]] users. Later the '''interface''' gets enriched with few [[default methods]]. When you look at an implementation of the interface which doesn't override the default methods: What can you conclude?	+
-		+
-	Either they don't implement the [[default methods]] as they weren't existing when the implementations were written - e.g. they compiled against original version of the [[API]]. Or they don't implement the [[default methods]] because they are happy with their default implementation. That may make (and does make) a difference! But it is impossible to separate these two cases apart!	+
-		+
-	~~[[TBD~~]]	+

JaroslavTulach at 10:30, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:30:36 GMT

←Older revision		Revision as of 10:30, 5 March 2018
Line 5:		Line 5:
	From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe - e.g. use it as [[ProviderAPI]].		From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe - e.g. use it as [[ProviderAPI]].

-	~~When you get~~ into situation ~~you are~~ going to welcome [[default methods]] as a nice way to help ~~you~~ get out of the corner. ~~Being able to add~~ [[default methods]] ~~is then welcomed ability to~~ enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. ~~However the concept of [[default methods]] also comes with drawbacks.~~	+	Later one needs to add new methods into the [[ClientAPI]] side of the contract. In such situation one is going to welcome [[default methods]] as a nice way to help one get ''out of the corner''. By adding [[default methods]] one can enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''.
-		+

		+	However the concept of [[default methods]] also comes with drawbacks.

	== Increasing Fuzziness ==		== Increasing Fuzziness ==

JaroslavTulach at 10:28, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:28:26 GMT

←Older revision		Revision as of 10:28, 5 March 2018
Line 3:		Line 3:
	== Useful? ==		== Useful? ==

-	From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe).	+	From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe - e.g. use it as [[ProviderAPI]].

	When you get into situation you are going to welcome [[default methods]] as a nice way to help you get out of the corner. Being able to add [[default methods]] is then welcomed ability to enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. However the concept of [[default methods]] also comes with drawbacks.		When you get into situation you are going to welcome [[default methods]] as a nice way to help you get out of the corner. Being able to add [[default methods]] is then welcomed ability to enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. However the concept of [[default methods]] also comes with drawbacks.

JaroslavTulach at 10:27, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:27:19 GMT

←Older revision		Revision as of 10:27, 5 March 2018
Line 1:		Line 1:
-	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept ~~(in case~~ one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]). ~~However the concept of~~ [[~~default methods~~]] ~~also comes with drawbacks. In case you have published an~~ [[API]] ~~full of interfaces (~~like {{JDK\|java/util\|List}} ~~that~~ people use as [[ClientAPI]], you are going to welcome the ~~ability~~ to add ~~few~~ [[default methods]] to ~~such~~ interface (~~just like~~ the [[~~JDK~~]] ~~team did)~~.	+	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]].
		+
		+	== Useful? ==
		+
		+	From one point of view, it is a useful concept. Especially if one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]. If one mixes [[APIvsSPI\|client and provider]] [[API]] into one type - like {{JDK\|java/util\|List}}, then one gets into trouble. On one side people call into the type (e.g. use it as [[ClientAPI]]). On the other hand, they also implement it - like {{JDK\|java/util\|ArrayList}} - but also numerous custom implementations written by developers around the globe).
		+
		+	When you get into situation you are going to welcome [[default methods]] as a nice way to help you get out of the corner. Being able to add [[default methods]] is then welcomed ability to enhance the [[ClientAPI]] part of the interface, while keeping (most of) the compatibility for those who implement the '''interface'''. However the concept of [[default methods]] also comes with drawbacks.
		+
		+

	== Increasing Fuzziness ==		== Increasing Fuzziness ==

JaroslavTulach at 10:17, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:17:33 GMT

←Older revision		Revision as of 10:17, 5 March 2018
Line 1:		Line 1:
-	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints himself into a corner by not following advices of [[TheAPIBook]])~~, but it~~ also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).	+	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints himself into a corner by not following advices of [[TheAPIBook]] when designing the first version of the [[API]]). However the concept of [[default methods]] also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).

	== Increasing Fuzziness ==		== Increasing Fuzziness ==

JaroslavTulach at 10:16, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:16:44 GMT

←Older revision		Revision as of 10:16, 5 March 2018
Line 1:		Line 1:
-	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints ~~itself~~ into a corner by not following advices of [[TheAPIBook]]), but it also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).	+	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints himself into a corner by not following advices of [[TheAPIBook]]), but it also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).

	== Increasing Fuzziness ==		== Increasing Fuzziness ==

JaroslavTulach at 10:16, 5 March 2018

JaroslavTulach — Mon, 05 Mar 2018 10:16:28 GMT

←Older revision		Revision as of 10:16, 5 March 2018
Line 1:		Line 1:
-	An ability to add implementation of [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints itself into a corner by not following advices of [[TheAPIBook]]), but it also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).	+	An ability to add ('''default''') implementation for [[Java]] '''interface''' methods available since [[JDK8]] is called [[default methods]]. From one point of view, it is a useful concept (in case one paints itself into a corner by not following advices of [[TheAPIBook]]), but it also comes with drawbacks. In case you have published an [[API]] full of interfaces (like {{JDK\|java/util\|List}} that people use as [[ClientAPI]], you are going to welcome the ability to add few [[default methods]] to such interface (just like the [[JDK]] team did).

	== Increasing Fuzziness ==		== Increasing Fuzziness ==

JaroslavTulach: /* Increasing Fuzziness */

JaroslavTulach — Mon, 05 Mar 2018 10:12:47 GMT

Increasing Fuzziness

←Older revision		Revision as of 10:12, 5 March 2018
Line 5:		Line 5:
	However '''interface''' with [[default methods]] is [[clarity\|fuzzier]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.		However '''interface''' with [[default methods]] is [[clarity\|fuzzier]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.

-	When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.	+	When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases [[fuzziness]]. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.

	Envision a pure '''interface''' defined in an initial version. Imagine the interface being implemented by various parties [[API]] users. Later the '''interface''' gets enriched with few [[default methods]]. When you look at an implementation of the interface which doesn't override the default methods: What can you conclude?		Envision a pure '''interface''' defined in an initial version. Imagine the interface being implemented by various parties [[API]] users. Later the '''interface''' gets enriched with few [[default methods]]. When you look at an implementation of the interface which doesn't override the default methods: What can you conclude?

JaroslavTulach: /* Increasing Fuzziness */

JaroslavTulach — Mon, 05 Mar 2018 10:12:24 GMT

Increasing Fuzziness

←Older revision		Revision as of 10:12, 5 March 2018
Line 3:		Line 3:
	== Increasing Fuzziness ==		== Increasing Fuzziness ==

-	However '''interface''' with [[default methods]] is [[~~fuzzier\|~~clarity]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.	+	However '''interface''' with [[default methods]] is [[clarity\|fuzzier]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.

	When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.		When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.

JaroslavTulach: /* Increasing Fuzziness */

JaroslavTulach — Mon, 05 Mar 2018 10:11:55 GMT

Increasing Fuzziness

←Older revision		Revision as of 10:11, 5 March 2018
Line 3:		Line 3:
	== Increasing Fuzziness ==		== Increasing Fuzziness ==

-	However '''interface''' with [[default methods]] is fuzzier than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.	+	However '''interface''' with [[default methods]] is [[fuzzier\|clarity]] than pure '''interface''' (without any implementation). '''interface''' with some (default) implementation no longer clearly defines a contract - e.g. its use for [[ProviderAPI]] is no longer as sharp as it could be.

	When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.		When somebody implements such '''interface''', one can choose to implement the '''default''' methods or ignore them. That increases fuzziness. Moreover when we look at the concept from the [[evolution]] point of view, it may get even fuzzier.