cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject RE: protected vs private instance members (in Woody)
Date Tue, 08 Jul 2003 10:29:12 GMT
Sylvain Wallez wrote:
> Sure. But then, one way or the other, the contract of the class with its
> subclasses is changed, and the subclasses are broken !
Yepp, but I think in this case it's ok, the subclasses have to be adjusted
accordingly. You can't make implementations 100% compatible and declaring
instance members as private doesn't help in open source.

Has someone followed the changes to regarding the component
It started as private was changed to protected and then changed to public
by someone who needed it (also it was never meant to be public!). But as
it's open source with so many developers, someone changes it and in
most cases this goes unnoticed.
Then someday someone noticed that and changed it back to protected. Later
on it was changed to public again and this went on for a while!
Now, finally we have a public getComponentManager method, although this
was never meant to be publically available.

Putting it short: even if the original author thinks that something is
really only private, someone else has a different opinion and changes
it. But for whatever reason, it might be unavoidable to change the
implementation breaking this.

> Agree, but that's theory : as long as a member or method is accessible,
> you can be sure someone will use it.

Yes, why not? And in the rare cases where the implementation changes
the subclass will break sometime. But as the contract is defined by the
interface the original class does still the same task as before but
with a different implementation. So the subclass could be changed
accordingly. Ok, this is theory as well, I know. It's even academic.
How often does an implementation change? I think it's an acceptable risk.

> 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;
> experimental.
> 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 ?
Yes, this is a good idea, but I'm not sure if it's practical. It requires
alot of discipline for everyone. But we could try it with the default
"internal" or "experimental".


View raw message