You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Martin Cooper <ma...@tumbleweed.com> on 2002/08/16 00:21:39 UTC
RE: [VOTE] RESULT XxxUtils constructors
> -----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" <ma...@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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>