cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <brettmclaugh...@earthlink.net>
Subject Class Naming, SAX 2.0, and Cocoon 2.0
Date Wed, 09 Feb 2000 20:05:29 GMT
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.

Thanks,
Brett

Mime
View raw message