PullXorPush - Revision history

JaroslavTulach: /* Don't Pull & Push at Once! */

2017-06-19T07:42:53Z

Don't Pull & Push at Once!

←Older revision		Revision as of 07:42, 19 June 2017
Line 38:		Line 38:
	== Don't Pull & Push at Once! ==		== Don't Pull & Push at Once! ==

-	The thing to remember is that (unless there are [[ImpossibleThreading\|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. ~~One~~ can always turn push into pull:	+	The thing to remember is that (unless there are [[ImpossibleThreading\|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. Your [[API]] users can always turn push into pull themselves:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Pull like Approach */

2017-06-19T07:42:06Z

Pull like Approach

←Older revision		Revision as of 07:42, 19 June 2017
Line 32:		Line 32:
	}		}
	</source>		</source>
-	This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the ~~language~~ implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.	+	This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the translation implementation that can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

	This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.		This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

JaroslavTulach: /* Pull like Approach */

2017-06-19T07:40:39Z

Pull like Approach

←Older revision		Revision as of 07:40, 19 June 2017
Line 20:		Line 20:
	== Pull like Approach ==		== Pull like Approach ==

-	Why register everything at the beginning? It is not even clear the registered translation will really be needed. In such open-ended system, it is very likely better to ~~try~~ a '''pull'''-like pattern:	+	Why register everything at the beginning? It is not even clear the registered translation will really be needed. In such open-ended system, it is very likely better to apply a '''pull'''-like pattern:
	<source lang="java">		<source lang="java">
	public interface Translate {		public interface Translate {

JaroslavTulach: /* Push like Example */

2017-06-19T07:40:10Z

Push like Example

←Older revision		Revision as of 07:40, 19 June 2017
Line 16:		Line 16:
	</source>		</source>

-	in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.	+	in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to delay such query and only ask when really needed.

	== Pull like Approach ==		== Pull like Approach ==

JaroslavTulach at 07:38, 19 June 2017

2017-06-19T07:38:54Z

←Older revision		Revision as of 07:38, 19 June 2017
Line 1:		Line 1:
-	The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for ~~full~~ symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush\|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.	+	The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for an absolute symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush\|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.

	== Push like Example ==		== Push like Example ==

JaroslavTulach: /* Don't Pull & Push at Once! */

2017-06-16T13:50:45Z

Don't Pull & Push at Once!

←Older revision		Revision as of 13:50, 16 June 2017
Line 64:		Line 64:
	</source>		</source>

-	It is easy to mimic '''push''' approach when you have a chance to to register for a '''pull'''. Just like avoiding both [[~~SettersAndGetters~~]], never support both [[PullXorPush\|pull & push]] in the same core [[API]].	+	It is easy to mimic '''push''' approach when you have a chance to to register for a '''pull'''. Just like avoiding both [[GettersAndSetters]], never support both [[PullXorPush\|pull & push]] in the same core [[API]].

	[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]]		[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Anti]]

JaroslavTulach: /* Don't Pull & Push at Once! */

2017-06-16T13:50:01Z

Don't Pull & Push at Once!

←Older revision		Revision as of 13:50, 16 June 2017
Line 38:		Line 38:
	== Don't Pull & Push at Once! ==		== Don't Pull & Push at Once! ==

-	The thing to remember is that (unless there are threading ~~issues~~), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. One can always turn push into pull:	+	The thing to remember is that (unless there are [[ImpossibleThreading\|threading concerns]]), it is always possible to simulate the '''push''' approach with the '''pull''' one. E.g. it makes no sense to design an [[API]] that supports both - prefer the '''pull''' approach as the more flexible one. One can always turn push into pull:

	<source lang="java">		<source lang="java">

JaroslavTulach: /* Pull like Approach */

2017-06-16T13:48:01Z

Pull like Approach

←Older revision		Revision as of 13:48, 16 June 2017
Line 32:		Line 32:
	}		}
	</source>		</source>
-	This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[~~Annotation Processor~~]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the language implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.	+	This has some benefits (and it can even be improved to work without the '''registerTranslation''' method with [[Lookup]] based registration or even more with [[AnnotationProcessor]]s) over the '''push''' version. One doesn't have to load languages until they are really needed. Also one can translate unknown words - if the word to translate is in plural, it is the language implementation can make additional adjustments and convert it to singular form, translate it and then (in the target language) translate it back to plural. Or one can translate even words that don't make sense - by looking up the closest alternative.

	This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.		This is the value of the '''pull'''-approach - one gets a callback and can adjust to it when needed.

JaroslavTulach at 13:46, 16 June 2017

2017-06-16T13:46:44Z

←Older revision		Revision as of 13:46, 16 June 2017
Line 16:		Line 16:
	</source>		</source>

-	in a system of such kind you require all translation [[~~modules~~]] (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.	+	in a system of such kind you require all translation [[module]]s (it probably makes sense to assume the translations are developed independently, right?) to eagerly - e.g. as early as possible - register themselves into the system and provide necessary details. From which language they translate words, to which language and what is the vocabulary they can handle. This is probably too premature - better to ask when needed.

	== Pull like Approach ==		== Pull like Approach ==

JaroslavTulach at 13:46, 16 June 2017

2017-06-16T13:46:15Z

←Older revision		Revision as of 13:46, 16 June 2017
Line 1:		Line 1:
-	The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry ~~and~~ how harmful ~~seek~~ for full symmetry can be ~~- the~~ chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters are enough. Similar example can be given for pull vs. push [[API]]s - it is unlikely you need both of them at once.	+	The [[Extreme Advice Considered Harmful]] chapter of [[TheAPIBook]] talks about symmetry. It describes how harmful seeking for full symmetry at all costs can be. The chapter argues that there often isn't a need for both [[GettersAndSetters]], that in many cases just getters in an [[API]] are enough. Similar example can be given for [[PullXorPush\|pull vs. push]] in [[API]]s - it is unlikely you need both of them at once.

	== Push like Example ==		== Push like Example ==