Visitor - Revision history

JaroslavTulach: /* JDK8 and Default methods */

2018-03-05T11:28:17Z

JDK8 and Default methods

←Older revision		Revision as of 11:28, 5 March 2018
Line 31:		Line 31:
	}		}
	</source>		</source>
-	however that hurts the [[clarity]] of a specified version. When I see an implementation of the interface without the ''visitMinus'' method being overriden, what does that mean? Does that mean that the implementation was written against version 1.0? Or that it has been written against version 2.0, but the '''default''' method implementation is fine? This makes a difference as the [[ClarityOfAccessModifiers\|arithmetica example]] demonstrates!	+	however that hurts the [[clarity]] of the specified version. When I see an implementation of the interface without the ''visitMinus'' method being overriden, what does that mean? Does that mean that the implementation was written against version 1.0? Or that it has been written against version 2.0, but the '''default''' method implementation is fine? This makes a difference as the [[ClarityOfAccessModifiers\|arithmetica example]] demonstrates!

	As such rather create new pure '''interface''' for each version of your language/expressions rather than relying on [[default methods]]. Don't be lazy, don't increase [[fuzziness]] of your [[API]]!		As such rather create new pure '''interface''' for each version of your language/expressions rather than relying on [[default methods]]. Don't be lazy, don't increase [[fuzziness]] of your [[API]]!

JaroslavTulach: /* JDK8 and Default methods */

2018-03-05T11:27:29Z

JDK8 and Default methods

←Older revision		Revision as of 11:27, 5 March 2018
Line 17:		Line 17:
	== JDK8 and [[Default methods]] ==		== JDK8 and [[Default methods]] ==

-	Can the extensible [[visitor]] pattern by simplified by usage of [[default methods]]? No, not really. Usage of [[default methods]] only increases [[fuzziness]] and goes against [[cluelessness]] of the users of the [[API]]. A general example can be found at the [[default methods]] page, here is its application to the [[visitor]] case:	+	Can the extensible [[visitor]] pattern be simplified by usage of [[default methods]]? No, not really. Usage of [[default methods]] only increases [[fuzziness]] and goes against [[cluelessness]] of the users of the [[API]]. A general example can be found at the [[default methods]] page, here is its application to the [[visitor]] case:

	When introducing the version 2.0 of the interface, one might be tempted to add the ''visitMinus'' method into an existing interface:		When introducing the version 2.0 of the interface, one might be tempted to add the ''visitMinus'' method into an existing interface:

JaroslavTulach: /* JDK8 and Default methods */

2018-03-05T11:27:14Z

JDK8 and Default methods

←Older revision		Revision as of 11:27, 5 March 2018
Line 19:		Line 19:
	Can the extensible [[visitor]] pattern by simplified by usage of [[default methods]]? No, not really. Usage of [[default methods]] only increases [[fuzziness]] and goes against [[cluelessness]] of the users of the [[API]]. A general example can be found at the [[default methods]] page, here is its application to the [[visitor]] case:		Can the extensible [[visitor]] pattern by simplified by usage of [[default methods]]? No, not really. Usage of [[default methods]] only increases [[fuzziness]] and goes against [[cluelessness]] of the users of the [[API]]. A general example can be found at the [[default methods]] page, here is its application to the [[visitor]] case:

		+	When introducing the version 2.0 of the interface, one might be tempted to add the ''visitMinus'' method into an existing interface:
		+	<source lang="java">
		+	public interface Version10 {
		+	public boolean visitUnknown(Expression e);
		+	public void visitPlus(Plus s);
		+	public void visitNumber(Number n);

		+	public default void visitMinus(Minus s) {
		+	visitUnknown(s);
		+	}
		+	}
		+	</source>
		+	however that hurts the [[clarity]] of a specified version. When I see an implementation of the interface without the ''visitMinus'' method being overriden, what does that mean? Does that mean that the implementation was written against version 1.0? Or that it has been written against version 2.0, but the '''default''' method implementation is fine? This makes a difference as the [[ClarityOfAccessModifiers\|arithmetica example]] demonstrates!
		+
		+	As such rather create new pure '''interface''' for each version of your language/expressions rather than relying on [[default methods]]. Don't be lazy, don't increase [[fuzziness]] of your [[API]]!

	<comments/>		<comments/>

JaroslavTulach at 11:11, 5 March 2018

2018-03-05T11:11:06Z

←Older revision		Revision as of 11:11, 5 March 2018
Line 14:		Line 14:

	[[TheAPIBook]] has been written prior to [[JDK]] 1.8 being mainstream. It is thus fair to ask [[Visitor18\|does anything change with JDK8]] on the recommendations presented here?		[[TheAPIBook]] has been written prior to [[JDK]] 1.8 being mainstream. It is thus fair to ask [[Visitor18\|does anything change with JDK8]] on the recommendations presented here?
		+
		+	== JDK8 and [[Default methods]] ==
		+
		+	Can the extensible [[visitor]] pattern by simplified by usage of [[default methods]]? No, not really. Usage of [[default methods]] only increases [[fuzziness]] and goes against [[cluelessness]] of the users of the [[API]]. A general example can be found at the [[default methods]] page, here is its application to the [[visitor]] case:
		+
		+

	<comments/>		<comments/>

JaroslavTulach at 13:06, 2 March 2018

2018-03-02T13:06:31Z

←Older revision		Revision as of 13:06, 2 March 2018
Line 13:		Line 13:
	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.		This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.

-	[[TheAPIBook]] has been written prior to [[JDK]] 1.8 being mainstream. It is thus fair to ask [[does anything change with JDK8~~\|Visitor18~~]] on the recommendations presented here?	+	[[TheAPIBook]] has been written prior to [[JDK]] 1.8 being mainstream. It is thus fair to ask [[Visitor18\|does anything change with JDK8]] on the recommendations presented here?

	<comments/>		<comments/>

JaroslavTulach: Let's talk about JDK8 changes

2018-03-02T13:04:45Z

Let's talk about JDK8 changes

←Older revision		Revision as of 13:04, 2 March 2018
Line 12:		Line 12:

	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.		This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.
		+
		+	[[TheAPIBook]] has been written prior to [[JDK]] 1.8 being mainstream. It is thus fair to ask [[does anything change with JDK8\|Visitor18]] on the recommendations presented here?

	<comments/>		<comments/>

JaroslavTulach at 08:56, 24 November 2009

2009-11-24T08:56:15Z

←Older revision		Revision as of 08:56, 24 November 2009
Line 7:		Line 7:
	<source lang="java" snippet="visitor.clientprovider.v2"/>		<source lang="java" snippet="visitor.clientprovider.v2"/>

-	This is the most flexible solution. It uses a form of ''tripple'' dispatch - e.g. the ~~final~~ visit method called ~~on the~~ (implementation of the [[visitor]] interface) is determined by the expression type, version of the expression language and implementation of the [[visitor]] interface:	+	This is the most flexible solution. It uses a form of ''tripple'' dispatch - e.g. the actual ''visit'' method called (on some implementation of the [[visitor]] interface) is determined by the expression type, version of the expression language and implementation of the [[visitor]] interface:

	<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>		<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>

JaroslavTulach at 08:54, 24 November 2009

2009-11-24T08:54:15Z

←Older revision		Revision as of 08:54, 24 November 2009
Line 11:		Line 11:
	<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>		<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>

-	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] is enriched by ~~new and~~ new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.	+	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.

	<comments/>		<comments/>

JaroslavTulach at 08:53, 24 November 2009

2009-11-24T08:53:10Z

←Older revision		Revision as of 08:53, 24 November 2009
Line 1:		Line 1:
-		+	The [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]] discusses various approaches to implement [[visitor]] in an [[evolution\|evolvable]] [[API]]. The learning path itself is important, but to stress the important point, here is the code for the final solution of the [[expression problem]]:
-	The [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]] discusses various approaches to implement [[visitor]] in an evolvable [[API]]. The learning path itself is important, but to stress the important point, here is the code for the final solution of the [[expression problem]]:	+

	<source lang="java" snippet="visitor.clientprovider.v1"/>		<source lang="java" snippet="visitor.clientprovider.v1"/>

JaroslavTulach at 06:46, 4 November 2009

2009-11-04T06:46:27Z

←Older revision		Revision as of 06:46, 4 November 2009
Line 1:		Line 1:
-	~~#REDIRECT~~ [[~~Case_Study_of_Writing_the_Extensible_Visitor_Pattern~~]]	+
		+	The [[Case Study of Writing the Extensible Visitor Pattern\|Chapter 18]] discusses various approaches to implement [[visitor]] in an evolvable [[API]]. The learning path itself is important, but to stress the important point, here is the code for the final solution of the [[expression problem]]:
		+
		+	<source lang="java" snippet="visitor.clientprovider.v1"/>
		+
		+	The solution is using [[Java]] interfaces to represent expression elements and yet it is fully evolvable (one can always define new expression element interface). [[Visitor]] is not just a single class, but one [[Java]] interface and one [[Java]] final class. [[Visitor]]s written using this style are easily extensible. For example when adding support for ''Minus'' operation in version 2.0 one just adds:
		+
		+	<source lang="java" snippet="visitor.clientprovider.v2"/>
		+
		+	This is the most flexible solution. It uses a form of ''tripple'' dispatch - e.g. the final visit method called on the (implementation of the [[visitor]] interface) is determined by the expression type, version of the expression language and implementation of the [[visitor]] interface:
		+
		+	<source lang="java" snippet="visitor.clientprovider.dispatch.v3.l2"/>
		+
		+	This solution to the [[expression problem]] is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] is enriched by new and new ''dispatch'' methods with every version. The interface part of [[visitor]] is immutable, a fixed point, which stays the same for those who implement it. Each version defines its own unique interface (according to the list of expression types it supports). The internals of the [[API]] then bridge the ''dispatch'' methods to appropriate interface ''visit'' methods.
		+
		+	<comments/>
		+
		+	[[Category:APIDesignPatterns]]
		+	[[Category:APIDesignPatterns:Evolution]]