commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Cooper" <martin.coo...@tumbleweed.com>
Subject RE: [VOTE] RESULT XxxUtils constructors
Date Thu, 15 Aug 2002 22:21:39 GMT


> -----Original Message-----
> From: Stephen Colebourne [mailto:scolebourne@btopenworld.com]
> Sent: Thursday, August 15, 2002 2:39 PM
> To: Jakarta Commons Developers List
> Subject: Re: [VOTE] RESULT XxxUtils constructors
> 
> 
> From: "Michael A. Smith" <mas@apache.org>
> > On Thu, 15 Aug 2002, robert burrell donkin wrote:
> > > there is no consensus.
> >
> > agreed.
> 
> The problem is that the Jakarta voting rules don't help us 
> here. Given Henri
> and Michael also gave the result as 'inconclusive' I withdraw 
> my result
> declaration (gosh, that sounds very official).
> 
> The only way to move forward would seem to be another vote, 
> more tightly
> driven. However, there's probably time for another round of discussion
> first...

I originally voted for protected. However, I did so before seeing the
approach described below. If that will actually work for Velocity, then I'd
be happy to change my vote and jump in with the 'private' crowd.

--
Martin Cooper


> 
> > > > (Although we could probably argue about it forever ;-)
> > >
> > > the problem is that pushing this forward against 
> opposition bodes ill
> for
> > > a project that is attempting to encourage code reuse. the 
> class was
> > > developed in velocity but it can no longer be used. 
> instead, the stated
> > > position of the privateers is that velocity needs to be 
> changed. other
> > > projects and component beware.
> >
> > I don't think anyone said that velocity *needs* to change.  
> As far as I
> > can remember, the "privateers" asked why commons needs to 
> make beans out
> > of decidedly non-bean classes rather than velocity 
> accepting non-bean
> > classes.  Just because velocity says "beans-only", doesn't 
> mean that the
> > Utils need to be made into beans when they are not.
> >
> > In other words, we have some component (e.g. Velocity) that 
> only works
> > on beans, and another component (e.g. StringUtils) that is 
> not a bean,
> > and we're trying to get them to work together.  To begin with, it
> > already seems like a bad mix.  Neither side wants to change 
> things (i.e.
> > velocity doesn't want to accept non-bean classes to allow 
> static method
> > invocation on them, and us "privateers" don't want to make 
> a non-bean
> > class into a bean).
> >
> > However, that doesn't mean that things can't work without 
> making one of
> > the "sides" change to accomodate the other.  Paul posted a perfectly
> > reasonable bridge between the two, and I don't think anyone 
> has posted a
> > reason why it couldn't be used:
> >
> > public class Util {
> >   public StringUtils string() { return null; }
> >   public ObjectUtils object() { return null; }
> >   public CollectionUtils collection() { return null; }
> > }
> >
> > $foo.string().method()
> >
> > And, although I'm not that familiar with velocity, I'm guessing you
> > could get even do:
> >
> > public class Util {
> >   public StringUtils getString() { return null; }
> >   public ObjectUtils getObject() { return null; }
> >   public Collectionutils getCollection() { return null; }
> > }
> >
> > then, you could use:
> >
> > $foo.string.method()
> >
> > (i.e. without the "()")
> >
> > Is there a reason velocity users can't use this?  Doesn't 
> this bridge
> > the bean to non-bean gap?
> >
> > regards,
> > michael
> >
> >
> > --
> > 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>
> 
> 


--
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