SuperVsInner - Revision history

JaroslavTulach at 05:51, 24 September 2022

2022-09-24T05:51:55Z

←Older revision		Revision as of 05:51, 24 September 2022
Line 10:		Line 10:
	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

-	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our [[API]] users I want to recommend:	+	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our [[API]] users I want to recommend: When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!

-	~~When designing an~~ [[~~API~~]]~~, always make sure that~~ [[~~ClarityOfAccessModifiers\|you know better~~]] ~~than users of your [[API]]!~~	+	[[Category:APIDesignPatterns]] [[Category:APIDesignPatterns:Clarity]]
-		+
-	~~<comments/>~~	+

JaroslavTulach at 05:48, 24 September 2022

2022-09-24T05:48:31Z

←Older revision		Revision as of 05:48, 24 September 2022
Line 1:		Line 1:
-	I always felt that there is some clash between the general desire for [[OOP\|object oriented]] reuse and [[APIDesignPatterns\|principles of good API design]]. Proponents of reuse seem to advocate making every method virtual, every class subclassable, every behavior changeable. Those who maintained [[API]] of a framework for some time and tried to keep some degree of [[BackwardCompatibility]] know that opening up more than planned for will at the end [[Amoeba Model\|hurt the reuse]].	+	I always felt that there is some clash between the general desire for [[OOP\|object oriented]] reuse and [[APIDesignPatterns\|principles of good API design]]. Proponents of reuse seem to advocate making every method virtual, every class subclassable, every behavior changeable while exposing [[DeepHierarchy]] of inheritence. Those who maintained [[API]] of a framework for some time and tried to keep some degree of [[BackwardCompatibility]] know that opening up more than planned for will at the end [[Amoeba Model\|hurt the reuse]].

	I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.		I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.

JaroslavTulach at 05:43, 30 October 2011

2011-10-30T05:43:21Z

←Older revision		Revision as of 05:43, 30 October 2011
Line 5:		Line 5:
	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is named '''pubment''' and it is a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation'':		That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is named '''pubment''' and it is a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation'':

-	<source lang="java">	+	<source lang="java" snippet="superinner.java"/>
-	~~public abstract class JavaLikeExample {~~	+	<source lang="java" snippet="superinner.beta"/>
-	~~public final int callable() {~~	+
-	~~return 1 + theSlot();~~	+
-	}	+
-		+
-	~~protected abstract int theSlot();~~	+
-	}	+
-		+
-	~~public abstract class BetaLikeExample {~~	+
-	~~pubment int callable() {~~	+
-	~~int res~~ = ~~inner~~.~~callable();~~	+
-	~~return res + 1;~~	+
-	}	+
-	}	+
-		+
-	</~~source~~>	+
-		+
-		+

	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

JaroslavTulach at 12:46, 25 February 2010

2010-02-25T12:46:36Z

←Older revision		Revision as of 12:46, 25 February 2010
Line 3:		Line 3:
	I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.		I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.

-	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is named '''pubment''' and it is a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.	+	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is named '''pubment''' and it is a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation'':
		+
		+	<source lang="java">
		+	public abstract class JavaLikeExample {
		+	public final int callable() {
		+	return 1 + theSlot();
		+	}
		+
		+	protected abstract int theSlot();
		+	}
		+
		+	public abstract class BetaLikeExample {
		+	pubment int callable() {
		+	int res = inner.callable();
		+	return res + 1;
		+	}
		+	}
		+
		+	</source>
		+
		+

	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

JaroslavTulach at 12:42, 24 February 2010

2010-02-24T12:42:57Z

←Older revision		Revision as of 12:42, 24 February 2010
Line 7:		Line 7:
	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

-	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users I~~'d like~~ to ~~share this advice~~:	+	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our [[API]] users I want to recommend:

	When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!		When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!

	<comments/>		<comments/>

JaroslavTulach at 12:41, 24 February 2010

2010-02-24T12:41:03Z

←Older revision		Revision as of 12:41, 24 February 2010
Line 10:		Line 10:

	When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!		When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!
		+
		+	<comments/>

JaroslavTulach at 12:38, 24 February 2010

2010-02-24T12:38:29Z

←Older revision		Revision as of 12:38, 24 February 2010
Line 7:		Line 7:
	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

-	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users: When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!	+	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users I'd like to share this advice:
		+
		+	When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!

JaroslavTulach at 12:37, 24 February 2010

2010-02-24T12:37:29Z

←Older revision		Revision as of 12:37, 24 February 2010
Line 3:		Line 3:
	I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.		I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.

-	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is '''pubment''' a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.	+	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is named '''pubment''' and it is a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.

	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.		The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users: When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!		Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users: When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!

JaroslavTulach at 12:36, 24 February 2010

2010-02-24T12:36:17Z

←Older revision		Revision as of 12:36, 24 February 2010
Line 5:		Line 5:
	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is '''pubment''' a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.		That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is '''pubment''' a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.

-	The paper also explains why '''inner''' is more suitable for [[API]] design. ~~Let me~~ quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.	+	The paper also explains why '''inner''' is more suitable for [[API]] design. To quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.

-	~~In a name~~ of [[cluelessness]] of our users: ~~While~~ designing an [[API]] ~~(regardless whether in [[Java]] or [[Beta]] style)~~, always make sure that you know better than users of your [[API]]!	+	Regardless of using [[Java]] or [[Beta]] style and with the hope to support [[cluelessness]] of our users: When designing an [[API]], always make sure that [[ClarityOfAccessModifiers\|you know better]] than users of your [[API]]!

JaroslavTulach at 12:34, 24 February 2010

2010-02-24T12:34:30Z

←Older revision		Revision as of 12:34, 24 February 2010
Line 1:		Line 1:
-	I always felt that there is some clash between the general desire for [[OOP\|object oriented]] reuse and [[APIDesignPatterns\|principles of good API design]]. Proponents of ~~resuereuse~~ seem to advocate making every method virtual, every class subclassable, every behavior ~~changable~~. Those who maintained an [[API]] or a framework for some time and tried to keep some degree of [[BackwardCompatibility]] know that opening up more than ~~expected~~ will at the end hurt the reuse.	+	I always felt that there is some clash between the general desire for [[OOP\|object oriented]] reuse and [[APIDesignPatterns\|principles of good API design]]. Proponents of reuse seem to advocate making every method virtual, every class subclassable, every behavior changeable. Those who maintained [[API]] of a framework for some time and tried to keep some degree of [[BackwardCompatibility]] know that opening up more than planned for will at the end [[Amoeba Model\|hurt the reuse]].

-	I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed in this way - [[Beta]]. However I never had enough time to learn [[~~beta~~]] properly, I just read the specification. It felt somewhat ~~up side~~ down, but without practical experience it was hard to formulate exactly what was ~~up and what was down~~.	+	I attribute this to the way subclassing is done in [[Java]] or [[C]]++ or similar languages. For a long time I could not formulate that feeling, but I kept a thought back in my mind about an [[OOP]] language which is not flawed this way - [[Beta]]. However I never had enough time to learn [[Beta]] properly, I just read the specification. It felt somewhat down side up, but without practical experience it was hard to formulate exactly what was so attractive on this ''rotation''.

-	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways ~~how~~ to make these two worlds co-exist in piece.	+	That is why I am thankful to authors of [http://www.cs.utah.edu/plt/publications/oopsla04-gff.pdf Super and Inner — Together at Last!] for explaining everything in the [[Java]] terminology and even finding ways to make these two worlds co-exist in piece. The paper also proposes new access modifier (which I called for in my [[ClarityOfAccessModifiers]] essay). It is '''pubment''' a perfectly fine (from [[API]] design perspective) combination of '''callable''' and '''slot''' which allows ''augmentation''.
		+
		+	The paper also explains why '''inner''' is more suitable for [[API]] design. Let me quote: The overall philosophy of class extension in [[Java]]-like languages (using '''super''') is: ''subclass implementors know better''. The philosophy of class extension in [[Beta]]-like languages (with '''inner''') is: ''superclass implementors know better''.
		+
		+	In a name of [[cluelessness]] of our users: While designing an [[API]] (regardless whether in [[Java]] or [[Beta]] style), always make sure that you know better than users of your [[API]]!