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]]

 

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''.

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"/>

<source lang="java" snippet="superinner.beta"/>

 

 

int res = inner.callable();

 

</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''.

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'':

 

 

 

int res = inner.callable();

 

 

 

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''.

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/>

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]]!

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]]!

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]]!

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]]!

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''.