Visitor18 - Revision history

JaroslavTulach at 13:16, 2 March 2018

2018-03-02T13:16:42Z

←Older revision		Revision as of 13:16, 2 March 2018
Line 1:		Line 1:
-	Does any new feature of [[~~JDK~~]]8 change the way people shall write [[visitor]]?	+	Does any new feature of [[JDK8]] change the way people shall write [[visitor]]?

	The solution to the [[expression problem]] - e.g. to write an extensible [[visitor]] - presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.		The solution to the [[expression problem]] - e.g. to write an extensible [[visitor]] - presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.

JaroslavTulach at 13:16, 2 March 2018

2018-03-02T13:16:05Z

←Older revision		Revision as of 13:16, 2 March 2018
Line 1:		Line 1:
	Does any new feature of [[JDK]]8 change the way people shall write [[visitor]]?		Does any new feature of [[JDK]]8 change the way people shall write [[visitor]]?

-	The solution to the [[expression problem]] - e.g. to write an extensible [[visitor]] - presented at the [[visitor]] page (and also [[Chapter 18]] of [[~~TheAPIBoook~~]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.	+	The solution to the [[expression problem]] - e.g. to write an extensible [[visitor]] - presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.

JaroslavTulach at 13:15, 2 March 2018

2018-03-02T13:15:51Z

←Older revision		Revision as of 13:15, 2 March 2018
Line 1:		Line 1:
-	Does any new feature of [[JDK]]8 change the way people shall write [[visitor]]"?	+	Does any new feature of [[JDK]]8 change the way people shall write [[visitor]]?

-	The solution to the [[expression problem]] presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBoook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.	+	The solution to the [[expression problem]] - e.g. to write an extensible [[visitor]] - presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBoook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.

JaroslavTulach: New page: Does any new feature of JDK8 change the way people shall write visitor"? The solution to the expression problem presented at the visitor page (and also Chapter 18 of ...

2018-03-02T13:13:55Z

New page: Does any new feature of JDK8 change the way people shall write visitor"? The solution to the expression problem presented at the visitor page (and also Chapter 18 of ...

New page

Does any new feature of [[JDK]]8 change the way people shall write [[visitor]]"?

The solution to the [[expression problem]] presented at the [[visitor]] page (and also [[Chapter 18]] of [[TheAPIBoook]]) is another realization of the general principle to separate [[ClientAPI]] from [[ProviderAPI]]. Client part of the [[visitor]] can be enriched by adding new ''dispatch'' methods (into '''final''' class) with each new 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.

[[Category:APIDesignPatterns]]
[[Category:APIDesignPatterns:Evolution]]