You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Stephen Colebourne <sc...@btopenworld.com> on 2002/08/18 15:47:12 UTC
Comment on (re-vote) XxxUtils constructors
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> On 8/18/02 9:18 AM, "Stephen Colebourne" <sc...@btopenworld.com>
> But if the votes don't pass, then you will go with 'private CTOR',
something
> no one can vote on.
>
> I think that isn't too cool. Didn't this start when the public CTOR was
> changed w/o vote to private, and Jason pointed it out?
Jason was using the sandbox version of [lang]. During the tidying up for
promotion we fixed this as a bug fix, because private is the current
standard.
Result from last round of voting:
>Henri says:
> ( ) public
> (4) private
> (2) protected
> ( ) This is up to each individual project
> ( ) Just worry about classes that Velocity might use
> (3) @deprecated public
> ( ) @deprecated protected
> Ignoring people's +0's, -0's and -1's.
> A pretty hung decision so far.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> Jason was using the sandbox version of [lang]. During the tidying up for
> promotion we fixed this as a bug fix, because private is the current
> standard.
Correction: there was no standard.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> On 8/18/02 9:47 AM, "Stephen Colebourne" <sc...@btopenworld.com>
> > Jason was using the sandbox version of [lang]. During the tidying up for
> > promotion we fixed this as a bug fix, because private is the current
> > standard.
>
> I see. I appreciate standards when there is a point. What's the point of
> this one?
>
> This isn't what velocity might use. It's what *users* of Velocity might
> use. The Velocity core doesn't need such things - but users tend to use
> Velocity in frameworks where they setup lists of classes of which
instances
> are made available for use in the template.
>
> We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
> people to share and use. If they now are going to evolve so people using
> Velocity and Turbine and Maverick and WebWork and... Can't share and use
> them, we'll just have to either make wrappers (stupid) or fork (even
> stupider) and keep available in Velocity or Turbine projects.
OK, I'll summarise the points.
The privateers argue:
These classes are just convenient places to place isolated methods. They
should not be instantiated, that wastes memory and is misleading to users.
ie. you don't need to instantiate to get the functionality. The Velocity
engine currently prevents these classes from being used, and there are
examples in Sun Java, java.util.Collections being notable. The core Velocity
engine could be changed to enable these classes to work, which would enable
access to all similar classes, whereas changing commons only allows access
to commons utility classes.
The protectedeers argue:
Sometimes it is useful to subclass utility classes, not because of an 'is a'
relationship, but simply to add more static utility methods. If Sun's
classes had protected constructors then commons CollectionsUtils would
probably have extended Sun's Collections. A protected constructor was
suggested as being acceptable to Velocity, however, it would appear to
suffer from the same issue of non-instantiability as private as its in a
different package.
The deprecated publiceers argue:
These classes are just convenient places to place isolated methods. They
should not be instantiated. However, tools such as Velocity have demostrated
that instantiation may be needed in certain circumstances. To enable
Velocity et al the constructor must be public. To disuade other coders from
instantiating the class it should be marked as deprecated, hance generating
a warning.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by Jason van Zyl <ja...@zenplex.com>.
On Sun, 2002-08-18 at 20:01, Steve Downey wrote:
> Jason van Zyl recently complained about code reformatting. I think that's
> wrong. Commons owns the code, regardless of where it came from. Local
> conventions should apply. If Turbine adopts the commons fileupload, they
> won't ever see the source. However, if it were changed in some way that made
> it really unuseable for Turbine, he'd have a legit gripe.
First of all: what local convention? Sun coding style? That certainly
has not been decided upon as a local convention. It's listed as a
resource in the charter but not compulsory as far as I'm aware.
When I see a coding style in a commons package and make additions I use
the existing style, used by the original authors. There are mixed styles
in all packages.
The fileupload code came from Turbine originally and with it the coding
convention. I asked politely to put it back the way it was, and that
checkstyle could be made to adhere to the original style.
The code may be in the Commons but I don't think it is unfair that the
original authors wishes be respected as far as coding conventions go.
That's just simple courtesy. I'm not in any way saying that Martin meant
any disrespect, I set up the checkstyle properties incorrectly so my
bad. I would just like it put back with the coding convention used when
it originally landed in the Commons.
It seems lately there is a muted hostility toward divergence from
'common' practice or convention while disregarding general pragmatism
and courtesy.
The public constructor business is definitely an example: where chunks
of the code originally came from Velocity and Turbine and a proposal is
actually considered that makes that code unusable to those projects in a
direct form. Geir was an original proponents of the commons and pushed
to make code reusable and to disregard the spirit of that effort, even
in the face of stated technical/stylistic reasons seems unreasonable to
me.
The same goes with the stated disregard to having code that originally
came from Turbine being left using the Turbine coding conventions. To me
that also seems unreasonable.
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by Daniel Rall <dl...@finemaltcoding.com>.
Steve Downey <st...@netfolio.com> writes:
> On Sunday 18 August 2002 09:55 am, Geir Magnusson Jr. wrote:
> > On 8/18/02 9:47 AM, "Stephen Colebourne" <sc...@btopenworld.com>
> >
> <SNIP/>
> > I'm sorry if this is something everyone has gone over before.
> >
> > This isn't what velocity might use. It's what *users* of Velocity might
> > use. The Velocity core doesn't need such things - but users tend to use
> > Velocity in frameworks where they setup lists of classes of which instances
> > are made available for use in the template.
> >
> > We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
> > people to share and use. If they now are going to evolve so people using
> > Velocity and Turbine and Maverick and WebWork and... Can't share and use
> > them, we'll just have to either make wrappers (stupid) or fork (even
> > stupider) and keep available in Velocity or Turbine projects.
>
> If one of the goals of commons is to take reuseable code out of projects like
> Velocity, Avalon and Tomcat, and make them generically useful, it seems to me
> to be terribly counterproductive to take their code and make it useless for
> the donor project. Not just change the API a little, but make it completely
> unuseable.
Indeed, nothing but agreement here Steve.
> Now, I can see the arguments that it should be possible for Velocity to
> execute static methods on an object without an instance of the object. But it
> can't. It isn't likely to soon. So a known client of the StringUtils class is
> not going to be able to use it. Period. Forking it isn't a question. Commons
> has already forked it.
Not to split hairs, but Velocity in fact can be configured to do just
that. However, to accomplish this you have to plug in an alternate
introspection engine! Requiring donor projects to jump through hoops
to re-use the code which they donated doesn't make sense, and as Steve
alludes to, is clearly not in the spirit the Commons charter.
> Jason van Zyl recently complained about code reformatting. I think that's
> wrong. Commons owns the code, regardless of where it came from. Local
> conventions should apply. If Turbine adopts the commons fileupload, they
> won't ever see the source. However, if it were changed in some way that made
> it really unuseable for Turbine, he'd have a legit gripe.
If only that were true. Looking at the active developers for many of
the Commons projects, you'll notice that (in the usual case) that they
consist primarily of developers from the donor project.
> There's no technical reason why instances of StringUtils can't be constructed.
> They're a bit useless in the Jave language, but quite useful in the Velocity
> language. They might be useful in other languages that run in the Java VM.
> Objections to the constructor amount to either, "I don't like that.", or
> "People who do that are dumb." Neither are good messages for a commons.
Indeed. Public constructors are necessary for Class.newInstance(),
and hence for common class loading implementations (the use case
pointed out for Velocity users).
It makes zero sense to reduce the usability of Commons code to placate
language lawyers.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by Steve Downey <st...@netfolio.com>.
On Sunday 18 August 2002 09:55 am, Geir Magnusson Jr. wrote:
> On 8/18/02 9:47 AM, "Stephen Colebourne" <sc...@btopenworld.com>
>
<SNIP/>
> I'm sorry if this is something everyone has gone over before.
>
> This isn't what velocity might use. It's what *users* of Velocity might
> use. The Velocity core doesn't need such things - but users tend to use
> Velocity in frameworks where they setup lists of classes of which instances
> are made available for use in the template.
>
> We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
> people to share and use. If they now are going to evolve so people using
> Velocity and Turbine and Maverick and WebWork and... Can't share and use
> them, we'll just have to either make wrappers (stupid) or fork (even
> stupider) and keep available in Velocity or Turbine projects.
>
If one of the goals of commons is to take reuseable code out of projects like
Velocity, Avalon and Tomcat, and make them generically useful, it seems to me
to be terribly counterproductive to take their code and make it useless for
the donor project. Not just change the API a little, but make it completely
unuseable.
Now, I can see the arguments that it should be possible for Velocity to
execute static methods on an object without an instance of the object. But it
can't. It isn't likely to soon. So a known client of the StringUtils class is
not going to be able to use it. Period. Forking it isn't a question. Commons
has already forked it.
Jason van Zyl recently complained about code reformatting. I think that's
wrong. Commons owns the code, regardless of where it came from. Local
conventions should apply. If Turbine adopts the commons fileupload, they
won't ever see the source. However, if it were changed in some way that made
it really unuseable for Turbine, he'd have a legit gripe.
There's no technical reason why instances of StringUtils can't be constructed.
They're a bit useless in the Jave language, but quite useful in the Velocity
language. They might be useful in other languages that run in the Java VM.
Objections to the constructor amount to either, "I don't like that.", or
"People who do that are dumb." Neither are good messages for a commons.
-SMD
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Comment on (re-vote) XxxUtils constructors
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/18/02 9:47 AM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:
> From: "Geir Magnusson Jr." <ge...@adeptra.com>
>> On 8/18/02 9:18 AM, "Stephen Colebourne" <sc...@btopenworld.com>
>> But if the votes don't pass, then you will go with 'private CTOR',
> something
>> no one can vote on.
>>
>> I think that isn't too cool. Didn't this start when the public CTOR was
>> changed w/o vote to private, and Jason pointed it out?
>
> Jason was using the sandbox version of [lang]. During the tidying up for
> promotion we fixed this as a bug fix, because private is the current
> standard.
I see. I appreciate standards when there is a point. What's the point of
this one?
> Result from last round of voting:
>> Henri says:
>> ( ) public
>> (4) private
>> (2) protected
>> ( ) This is up to each individual project
>> ( ) Just worry about classes that Velocity might use
I'm sorry if this is something everyone has gone over before.
This isn't what velocity might use. It's what *users* of Velocity might
use. The Velocity core doesn't need such things - but users tend to use
Velocity in frameworks where they setup lists of classes of which instances
are made available for use in the template.
We pushed stuff out of Velocity and Turbine into commons[-sandbox] for
people to share and use. If they now are going to evolve so people using
Velocity and Turbine and Maverick and WebWork and... Can't share and use
them, we'll just have to either make wrappers (stupid) or fork (even
stupider) and keep available in Velocity or Turbine projects.
>> (3) @deprecated public
>> ( ) @deprecated protected
>
>> Ignoring people's +0's, -0's and -1's.
>> A pretty hung decision so far.
>
I guess to me it's much ado about nothing - I can't see the downside....
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>