cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Class Naming, SAX 2.0, and Cocoon 2.0
Date Wed, 09 Feb 2000 21:23:03 GMT
Brett McLaughlin wrote:
> 
> All-
> 
>         In seeing Pier work on the Cocoon 2.0 branch, I notice that a lot of
> the names of Cocoon classes match up or are very similar to SAX 1.0
> class names, such as Configurable, ParserFactory, and others.  While I
> know that these names may often be appropriate descriptions, I wanted to
> at least bring up some questions about the names.  In addition to not
> being unique across the project space when SAX is present, which it must
> be, these names are now outdated in regards to SAX.
> 
>         So first, I might suggest we try to maintain uniqueness of class naming
> across a single project.  That would mean that is we know a class named
> Configurable or ParserFactory is part of org.xml.sax, we at least make
> an effort to avoid using the same names in, for example,
> org.apache.cocoon.framework.  Is this inconvenient?  Yes.  Is it
> impossible?  Only rarely.  However, it seems to just be good practice.
> Anyone who has coded JDBC and dealt with the difference between
> java.sql.Date and java.util.Date probably knows the annoyance and goofy
> coding this results in.
>         Second, I think confusion will only increase as these names are now
> part of *deprecated* classes and interfaces in SAX 2.0.  Both
> Configurable and ParserFactory are deprecated classes/interfaces from
> SAX 1.0 in SAX 2.0.  I saw a commit by Pier on the Configurable class
> (in Cocoon) and was halfway through writing a mail asking why he was
> still using a SAX 1.0 interface before realizing it was actually a
> Cocoon class.  Sure, I didn't look closely enough, but isn't our goal
> clarity in code?  How many others will make this similar or related
> mistakes?
> 
>         Finally, normally this sort of thing is impossible, as projects are so
> stabilized.  However, in Cocoon 2.0's birth, we have a chance to make
> changes like this while we can, and yet not affect the growth and
> continuity of the project.  Certainly a complete number version change
> allows that sort of thing, as well as the re-architecture that Cocoon
> 2.0 involves.
> 
>         So maybe you totally disagree, which is OK; please at least try to
> convince me why taking the time and trouble to avoid name collisions
> even across packages of the same project is a waste of time... I am
> interested.

I agree with you, we should avoid name collisions where possible.

Unfortunately, we came up with Configurable _far_ before SAX did :) And,
anyway, Configurable was added in SAX 2.0 alpha and it's now gone.
Cocoon is using the class names that Avalon is using so to make
integration smooth when Avalon will be widely use (not "if", "when" :)

Anyway, Pier, I don't like the XXXFactory classes too, let's come up
with better names...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

Mime
View raw message