cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: protected vs private instance members (in Woody)
Date Tue, 08 Jul 2003 08:49:18 GMT
Carsten Ziegeler wrote:

>Vadim Gritsenko wrote:
>>Carsten Ziegeler wrote:
>>>I hope this makes sense :) if not at all, we can revert it.
>>Not exactly; see Sylvain's response and in addition to it please recall 
>>a vote about flow model "add only very necessary things instead of 
>>adding all and everything you can think of" (majority agreed with the 
>>vote). Parallel between this flow vote and java private/protected 
>>members is easy to see: have everything private and open up only very 
>>necessary stuff. And, preferably, open up via accessor methods.
>This is really an interesting topic to discuss :)
>Now, I don't agree :) I think the contract we define is based on Interfaces and perhaps
on abstract implementations, but not on concrete implementations. You can't guarantee that
an implementation does not change over time.

Yes, but people that want to add functionality to a component will use 
all that is made available by this component. And this includes any 
protected method/member. Sure, the right thing to do would be to start 
from the interface, but we all know that programmers are lazy : why 
rewrite some code that already exists in one of the Cocoon classes, 
especially when they seem to be general-purpose abstract classes ?

>Some examples: assume you use an int as an instance variable and change it later on to
an object (Integer). Now, it's regardless if you make the variable private and have a getter
method or did make it protected.

Sure. But then, one way or the other, the contract of the class with its 
subclasses is changed, and the subclasses are broken !

>Or assume, we change from Composable to Serviceable which is a very legal change for an
implementation. Even a getter method for the component manager does not help as when implementing
Serviceable you don't have a component manager.

Sure, it is legal to change it in the implementation... if this 
particular implementation doesn't define a contract with subclasses ! 
Imagine what will happen if we change ComposerAction to implement 
Serviceable instead of Composable ! Most of user actions will suddenly 
be broken. And this will not be source-compatible like was the case with 
the move from AbstractLoggable to AbstractLogEnabled.

>So, I think implementations can change incompatible over time and if someone relies on
the implementation he has to change its implementation as well. The contracts (like the above
mentioned fom) are defined by interfaces.

Agree, but that's theory : as long as a member or method is accessible, 
you can be sure someone will use it. A solution to this may be to define 
those methods and members that we, Cocoon developpers, consider to be 
safe for use outside of the Cocoon code base. Xalan has a feature for 
this : they embed some <meta> tags in the javadoc that is later used to 
produce the Javadoc. This allows to build a public API where some of the 
class/members/methods that are public/protected from a syntactic point 
of view are removed from the produced documentation.

See e.g. the ExtensionHandler class [1] and the resulting Javadoc [2]. 
The values of the <meta> tag can be general, internal, advanced; 

By using this kind of feature (@usage would be better than <meta 
name="usage">), we can cleanly separate what we consider as "publicly 
available" (and that we guarantee to last) from what we make public for 
the needs of Cocoon development.

What do you think ?



Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance  -

View raw message