commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack, Paul" <pj...@sfaf.org>
Subject RE: [VOTE] (re-vote) XxxUtils constructors
Date Mon, 19 Aug 2002 18:10:43 GMT
Actually, now that I've purged, here's another idea. :)

1.  Constructors are public.  Yay, Velocity can use the 
utility classes.

2.  The utility classes are marked as final.  Yay, no one
can add instance methods or otherwise wreak havoc with the
API.

3.  People can waste memory with unneeded instances.  Boo,
but not a major show-stopper.

-Paul

> -----Original Message-----
> From: Jack, Paul [mailto:pjack@sfaf.org]
> Sent: Monday, August 19, 2002 11:01 AM
> To: 'Jakarta Commons Developers List'
> Subject: RE: [VOTE] (re-vote) XxxUtils constructors
> 
> 
> > <set sarcasm="on">
> > Oh, becuase you're an idiot who doesn't know any better, of course. 
> > 
> > What's that? You're using some other language that runs in 
> > the Java VM? Well 
> > why don't you change your language. 
> > 
> > Really, you'll be better off in the long run.
> > 
> >  In fact, if you'd just use Java in the first place, you 
> > wouldn't have these 
> > problems...
> > </set>
> 
> ...it's actually degraded to this point...
> 
> Right.  No one's clearly articulated a position on keeping 
> constructors private so I guess I'll do it.  Bear in mind 
> that I'm not adamantly against public constructors; I'll just 
> think they're really weird.  If my private vote were blocking 
> a public majority then I'd probably change it in the interests 
> of closure and solidarity.
> 
> I'll think they're really wierd because I don't use tools like 
> Velocity.  But fine, other people do.  The question in my mind
> is, should a general-purpose library like [lang] have requirements
> driven by specific projects like Velocity?  
> 
> Now my immediate answer is "no".  The reason is quite simple.  By
> tailoring an API to meet Velocity's needs, we might unwittingly
> be making life harder for other tools.
> 
> The present issue has to do with how a tool like Velocity might
> discover and use a particular class.  Velocity's approach is for
> users to manually specify the class name (I think), assign it
> to a variable name, instantiate the class, and map the variable
> name to that instance.  (I think).
> 
> Fine.  It's straightforward and immediately available to the user,
> well done.  But it's not the only way.  It also makes an arbitrary
> assumption that all useful objects will have public, no-argument
> constructors.  This is actually not an unreasonable assumption to 
> make.  Many APIs are based on JavaBeans, which mandate a public, 
> no-argument constructor; and many APIs that aren't based on JavaBeans,
> such as the Java Collections Framework, stipulate public, no-argument
> constructors.
> 
> But what if Velocity had made an opposite arbitrary assumption?  
> What if there's some tool out there that realizes that utility 
> libraries often follow the Collections pattern of private constructor
> and only static methods?  Such a tool might attempt to automatically
> discover such classes in a .jar file to make them immediately 
> available to a user, without that user having to specify the class
> name.
> 
> Which is probably a weak argument that won't move anybody, because
> I can't name such a tool.  But still, my point is just that the 
> audience for [lang] -- indeed for any Commons project -- is much 
> broader than particular existing tools.  Since the requirements of 
> particular tools might conflict with each other, the only 
> sensible approach to generic libraries like [lang], to me, is to
> fall back on good design principles.
> 
> A good design principle is to keep things as private as possible.
> It simply allows you much more flexibility to fix bugs and to make
> things more efficient.  There's a very inefficient class in 
> [collections] -- SoftRefHashMap -- that we couldn't directly fix,
> because it exposed all of its internals as protected fields and
> methods.  Had those fields been private, we could have erased them,
> replacing them with new algorithms that were much better, without
> affecting the public API or the end user.
> 
> With a public constructor, a coder in some Jakarta project might get
> the great idea of using StringUtils as the superclass of a Parser
> object, since the Parser object would rely heavily on StringUtils
> methods.  This is how junit works, in fact; its static class Assert
> is extended by test cases so that they inherit all the static 
> assertTrue, assertEquals methods.
> 
> But Assert is a stable API.  StringUtils isn't.  There are many as
> of yet undiscovered String utility methods that haven't been added
> yet.  So Joe Coder's Parser object is dandy until the [lang] people
> add a generic static parse(Object) method, which happens to have
> a different return type than the Parser.parse(Object) instance 
> method.  Now suddenly there has to be another holy war over who 
> gets to keep the concise method name.  [lang] would be hearing
> the exact same arguments from Joe Coder that it's currently
> hearing now from Velocity.
> 
> Keeping the constructor private does make technical sense.  It 
> makes technical sense to avoid potential issues with inheritance
> for a class that isn't really part of an inheritance hierarchy.
> It *especially* makes sense to avoid those issues wherever possible
> in a project like [lang], which will probably be used by the Whole
> Entire World.
> 
> Really, the people who voted for a private constructor aren't
> completely insane.  If those with an opposing viewpoint could possibly
> stop acting like we were, I, for one, would greatly appreciate it.
> 
> The "privateers", in fact, have been actively suggesting compromises,
> things that seemed like they would work within the existing Velocity
> scheme but not require a public constructor.  Those solutions turned
> out to be inadequate, as we discovered only after the 
> opposition stopped
> ignoring them completely.
> 
> The privateers have also been willing to mutate into things like 
> protected or deprecated public constructors, which would at least 
> prevent direct instantiation or issue severe warnings about the 
> practice of using the constructors.  To date these ideas have also
> been completely ignored.
> 
> The privateers have been doing all the work to resolve a contentious
> issue, and have been rewarded with hostility, insults and now
> base sarcasm.
> 
> We're not the ones who are irrational.  
> 
> Daniel Rall, the person who raised this issue, once accepted 
> protected 
> constructors as a simple way for Velocity to provide its own publicly 
> available versions of utility classes.
> 
> -Paul
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message