You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jason van Zyl <ja...@zenplex.com> on 2002/08/12 04:46:13 UTC
StringUtils constructor is private
Hi,
Can this be made public again? I upgrade a ton of things in Maven to use
the b1 and it broke things all over the place. I have used
StringUtils/Strings for a long time a tool inside a velocity context and
the private constructor puts a bit of a damper on this. Can we make this
public again?
--
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: StringUtils constructor is private
Posted by Juozas Baliuka <ba...@mwm.lt>.
It must not be a problem to add instance variable and to depricate public
constuctor,
it is not the best way to "remove" something if code has users.
----- Original Message -----
From: "Stephen Colebourne" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, August 12, 2002 10:18 AM
Subject: Re: StringUtils constructor is private
> >From what little I know about velocity I think I see the problem.
Velocity
> needs an object to make method calls against. StringUtils can't be an
> object. Hence the problem.
>
> However, really this is a Velocity issue, not a commons one. Its a general
> principle that all static utility classes (ie. those with only static
> methods) should have a private constructor. We don't want people creating
> instances, because they are not objects merely a convenient groupings of
> methods. If Velocity can't handle that it excludes virtually every static
> utility class.
>
> But given Velocity is broken, I suppose we have to do something. Either a
> public constructor or a public static final instance variable 'INSTANCE'
> would do. But I hate the very thought of it. And it affects all of
> [collections], [pattern and [lang].
>
> Stephen
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, August 12, 2002 6:44 AM
> Subject: Re: StringUtils constructor is private
>
>
> >
> > I don't see many reasons why not. I should be able to easily sneak out a
> > replacement jar for the beta without making a song and dance about it,
> > it's not something that will break on anyone.
> >
> > A bigger question, is why does it break things? I'm not a proponent of
> > privatising constructors without something to protect so am the easiest
> > person to convince, however if there's some kind of common tool which
can
> > only handle instance methods [and statics by pretending they're
instance]
> > then we should modify all Utils to have constructors unless absolutely
> > necessary.
> >
> > Is it a velocity thing?
> >
> > Hen
> >
> > On 11 Aug 2002, Jason van Zyl wrote:
> >
> > > Hi,
> > >
> > > Can this be made public again? I upgrade a ton of things in Maven to
use
> > > the b1 and it broke things all over the place. I have used
> > > StringUtils/Strings for a long time a tool inside a velocity context
and
> > > the private constructor puts a bit of a damper on this. Can we make
this
> > > public again?
> > >
> > > --
> > > 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>
> > >
> > >
> >
> >
> > --
> > 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>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> From: "Daniel Rall" <dl...@finemaltcoding.com>
> > "Stephen Colebourne" <sc...@btopenworld.com> writes:
> > > But given Velocity is broken, I suppose we have to do something. Either
> a
> > > public constructor or a public static final instance variable 'INSTANCE'
> > > would do. But I hate the very thought of it. And it affects all of
> > > [collections], [pattern and [lang].
> >
> > Velocity is not broken -- it simply requires a class instance to
> > reference methods of that class. Valid in Java, valid in Velocity.
>
> But Velocity shouldn't require the class instance. Reflection doesn't.
> Something like:
> context.putStatic("foo", StringUtils.class);
> #set ($bar = $foo.chomp())
In your example, there is no way to know whether you want to invoke
methods of the Class instance you added to the context, or methods of
the class which it represents.
That's why I suggested the following wrapper (which may even exist,
for all I know):
<repeat>
What would be really convenient is a class with hooks into the
Velocity internals which takes a Class object in its constructor and
invokes methods via reflection (much as Velocity does anyhow), using
Velocity's internal introspection and/or uberspection caches.
</repeat>
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> But Velocity shouldn't require the class instance. Reflection doesn't.
p.s. Velocity uses introspection, a layer which operates on top of
reflection.
http://developer.java.sun.com/developer/onlineTraining/Beans/Beans4/reflect00.html
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Daniel Rall" <dl...@finemaltcoding.com>
> "Stephen Colebourne" <sc...@btopenworld.com> writes:
> > But given Velocity is broken, I suppose we have to do something. Either
a
> > public constructor or a public static final instance variable 'INSTANCE'
> > would do. But I hate the very thought of it. And it affects all of
> > [collections], [pattern and [lang].
>
> Velocity is not broken -- it simply requires a class instance to
> reference methods of that class. Valid in Java, valid in Velocity.
But Velocity shouldn't require the class instance. Reflection doesn't.
Something like:
context.putStatic("foo", StringUtils.class);
#set ($bar = $foo.chomp())
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: StringUtils constructor is private
Posted by Paulo Gaspar <pa...@krankikom.de>.
> -----Original Message-----
> From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> Sent: Monday, August 12, 2002 11:22 PM
>
> ...
>
> What would be really convenient is a class with hooks into the
> Velocity internals which takes a Class object in its constructor and
> invokes methods via reflection (much as Velocity does anyhow), using
> Velocity's internal introspection and/or uberspection caches.
The hooking would be trivial by using:
- A special class just to hold the introspected class (as you mention);
- The custom instrospection mechanism.
So... yest another use for custom introspection!
=:oD
Have fun,
Paulo Gaspar
http://www.krankikom.de
http://www.ruhronline.de
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> From what little I know about velocity I think I see the problem. Velocity
> needs an object to make method calls against. StringUtils can't be an
> object. Hence the problem.
Correct.
> However, really this is a Velocity issue, not a commons one. Its a general
> principle that all static utility classes (ie. those with only static
> methods) should have a private constructor. We don't want people creating
> instances, because they are not objects merely a convenient groupings of
> methods. If Velocity can't handle that it excludes virtually every static
> utility class.
Any static method in Java is callable via an instance of the declaring
class. Just as Java supports this, Velocity does too. Example:
public class Foo {
public static String bar() { return new Object(); }
}
Foo.bar() -> Object
new Foo().bar() -> Object
context.put("foo", new Foo());
#set ($bar = $foo.bar())
> But given Velocity is broken, I suppose we have to do something. Either a
> public constructor or a public static final instance variable 'INSTANCE'
> would do. But I hate the very thought of it. And it affects all of
> [collections], [pattern and [lang].
Velocity is not broken -- it simply requires a class instance to
reference methods of that class. Valid in Java, valid in Velocity.
Other work-arounds include an instantiable extension class (meaning
we'd make the StringUtils constructor protected, perhaps a good idea
regardless), or a wrapper class which delegates to the utility methods
(which is fairly gross).
What would be really convenient is a class with hooks into the
Velocity internals which takes a Class object in its constructor and
invokes methods via reflection (much as Velocity does anyhow), using
Velocity's internal introspection and/or uberspection caches.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> From what little I know about velocity I think I see the problem. Velocity
> needs an object to make method calls against. StringUtils can't be an
> object. Hence the problem.
Correct.
> However, really this is a Velocity issue, not a commons one. Its a general
> principle that all static utility classes (ie. those with only static
> methods) should have a private constructor. We don't want people creating
> instances, because they are not objects merely a convenient groupings of
> methods. If Velocity can't handle that it excludes virtually every static
> utility class.
Any static method in Java is callable via an instance of the declaring
class. Just as Java supports this, Velocity does too. Example:
public class Foo {
public static String bar() { return new Object(); }
}
Foo.bar() -> Object
new Foo().bar() -> Object
context.put("foo", new Foo());
#set ($bar = $foo.bar())
> But given Velocity is broken, I suppose we have to do something. Either a
> public constructor or a public static final instance variable 'INSTANCE'
> would do. But I hate the very thought of it. And it affects all of
> [collections], [pattern and [lang].
Velocity is not broken -- it simply requires a class instance to
reference methods of that class. Valid in Java, valid in Velocity.
Other work-arounds include an instantiable extension class (meaning
we'd make the StringUtils constructor protected, perhaps a good idea
regardless), or a wrapper class which delegates to the utility methods
(which is fairly gross).
What would be really convenient is a class with hooks into the
Velocity internals which takes a Class object in its constructor and
invokes methods via reflection (much as Velocity does anyhow), using
Velocity's internal introspection and/or uberspection caches.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Stephen Colebourne <sc...@btopenworld.com>.
>From what little I know about velocity I think I see the problem. Velocity
needs an object to make method calls against. StringUtils can't be an
object. Hence the problem.
However, really this is a Velocity issue, not a commons one. Its a general
principle that all static utility classes (ie. those with only static
methods) should have a private constructor. We don't want people creating
instances, because they are not objects merely a convenient groupings of
methods. If Velocity can't handle that it excludes virtually every static
utility class.
But given Velocity is broken, I suppose we have to do something. Either a
public constructor or a public static final instance variable 'INSTANCE'
would do. But I hate the very thought of it. And it affects all of
[collections], [pattern and [lang].
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, August 12, 2002 6:44 AM
Subject: Re: StringUtils constructor is private
>
> I don't see many reasons why not. I should be able to easily sneak out a
> replacement jar for the beta without making a song and dance about it,
> it's not something that will break on anyone.
>
> A bigger question, is why does it break things? I'm not a proponent of
> privatising constructors without something to protect so am the easiest
> person to convince, however if there's some kind of common tool which can
> only handle instance methods [and statics by pretending they're instance]
> then we should modify all Utils to have constructors unless absolutely
> necessary.
>
> Is it a velocity thing?
>
> Hen
>
> On 11 Aug 2002, Jason van Zyl wrote:
>
> > Hi,
> >
> > Can this be made public again? I upgrade a ton of things in Maven to use
> > the b1 and it broke things all over the place. I have used
> > StringUtils/Strings for a long time a tool inside a velocity context and
> > the private constructor puts a bit of a damper on this. Can we make this
> > public again?
> >
> > --
> > 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>
> >
> >
>
>
> --
> 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>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Geir Magnusson Jr." <ge...@adeptra.com> writes:
> On the other hand, its a general thing : I think that for general utility
> classes that can be instantiated with an argless constructor, having it
> public makes it easy for any 'tool using' code that want to instantiate
> dynamically
Which is why I would prefer a protected to public ctor -- the use case
for instantiation is still open with minimal work on the user's part,
but it is not directly encouraged by the API.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by Berin Loritsch <bl...@apache.org>.
> From: Henri Yandell [mailto:bayard@generationjava.com]
>
> Resolution:
>
> I've built a version of the beta with StringUtils having a
> public constructor. Jason should be testing it out at some
> point soon to let me know if I screwed up.
> Does the private XxxUtils convention gain us anything? What
> do we care if someone makes an instance? It's ugly, but
> they're choosing the ugly.
It's nothing major, but if all the methods and variables are
static, creating a new StringUtils will not gain you anything.
Therefore, hiding the constructor prevents the misconception
that creating a new StringUtil() will really do anything besides
add additional crap for the GC to collect.
It doesn't gain much of anything to have/not have it.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Stephen Colebourne" <sc...@btopenworld.com> writes:
> I actually quite strongly dislike making the constructor public. Its
> basically a flaw in Velocity that we're coding for.
It is not a flaw. As I explained in my last message, a private
constructor hides features of Java which Velocity (any many, many
other pieces of code I've seen) take advantage of.
> However, in the spirit of cooperation, I am willing to see a public
> constructor. However, I want it to be deprecated. The deprecation won't
> affect tools like Velocity that instantiate it by Class.newInstance(), but
> will cause ordinary programmers to realise that they are using the class
> wrongly.
+1 on deprecation. I would also like to add a protected constructor
to allow usage of exotic Java language features (via sub-classing)
without directly encouraging instantiation of the utility classes.
> Also, if we do this to one static utility class, we do it to all. That means
> changing the [lang] developers guide and making the changes. It also affects
> [collections] and [pattern]
Indeed. +1 on protected constructors for all utility class.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang][collections] Utils having a public constructor
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 12 Aug 2002, Stephen Colebourne wrote:
> I actually quite strongly dislike making the constructor public. Its
> basically a flaw in Velocity that we're coding for.
>
> However, in the spirit of cooperation, I am willing to see a public
> constructor. However, I want it to be deprecated. The deprecation won't
> affect tools like Velocity that instantiate it by Class.newInstance(), but
> will cause ordinary programmers to realise that they are using the class
> wrongly.
Jason/Geir, is this acceptable?
>
> Also, if we do this to one static utility class, we do it to all. That means
> changing the [lang] developers guide and making the changes. It also affects
> [collections] and [pattern]
Agreed. We either go one way or the other. With the 'spirit of
cooperation' I aimed to do the minimal number of changes necessary.
Collections peoples... what is your viewpoint?
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
From: "Geir Magnusson Jr." <ge...@adeptra.com>
> > I actually quite strongly dislike making the constructor public. Its
> > basically a flaw in Velocity that we're coding for.
>
> Not quite clear to me that using Class.newInstance() to dynamically create
> instances is a flaw...
All I'm saying is that Velocity should be able to allow you to call a static
method without needing an instance. It is excluding every static utils
method class I've ever written until now by not doing so. Its a flaw because
the class shouldn't be instantiated.
Stephen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 2:56 PM, "Stephen Colebourne" <sc...@btopenworld.com>
wrote:
> I actually quite strongly dislike making the constructor public. Its
> basically a flaw in Velocity that we're coding for.
Not quite clear to me that using Class.newInstance() to dynamically create
instances is a flaw...
>
> However, in the spirit of cooperation, I am willing to see a public
> constructor. However, I want it to be deprecated. The deprecation won't
> affect tools like Velocity that instantiate it by Class.newInstance(), but
> will cause ordinary programmers to realise that they are using the class
> wrongly.
>
> Also, if we do this to one static utility class, we do it to all. That means
> changing the [lang] developers guide and making the changes. It also affects
> [collections] and [pattern]
>
> Stephen
>
> ----- Original Message -----
> From: "Henri Yandell" <ba...@generationjava.com>
> To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
> Sent: Monday, August 12, 2002 7:05 PM
> Subject: Re: [lang] Action-taken [Was: StringUtils constructor is private]
>
>
>>
>>
>> On Mon, 12 Aug 2002, Henri Yandell wrote:
>>
>>>
>>> Resolution:
>>>
>>> I've built a version of the beta with StringUtils having a public
>>> constructor. Jason should be testing it out at some point soon to let me
>>> know if I screwed up.
>>>
>>> My reasoning is:
>>>
>>> 1) I don't want to hold up another project's release wit such a minor
>>> issue.
>>>
>>> 2) I simply replaced the existing beta downloads as I don't believe that
>>> this represents a noticable API change. If I'm wrong, please show me
> that
>>> so I can hang my head in utter dejectedness. [I do have copies of the
> old
>>> downloads in my home directory, give me an ounce of credit :) ]
>>
>> In fact this is changed. There is now a commons-lang-1.0-b1.1 release with
>> a note on the release page specifying how it's a very tiny change from b1.
>> Releasing with a different version is smarter, and means that things like
>> Maven can handle the new versioning more easily.
>>
>> Hopefully that's enough messing around from me :)
>>
>> Hen
>>
>>
>> --
>> 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>
>
--
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>
Re: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I actually quite strongly dislike making the constructor public. Its
basically a flaw in Velocity that we're coding for.
However, in the spirit of cooperation, I am willing to see a public
constructor. However, I want it to be deprecated. The deprecation won't
affect tools like Velocity that instantiate it by Class.newInstance(), but
will cause ordinary programmers to realise that they are using the class
wrongly.
Also, if we do this to one static utility class, we do it to all. That means
changing the [lang] developers guide and making the changes. It also affects
[collections] and [pattern]
Stephen
----- Original Message -----
From: "Henri Yandell" <ba...@generationjava.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Monday, August 12, 2002 7:05 PM
Subject: Re: [lang] Action-taken [Was: StringUtils constructor is private]
>
>
> On Mon, 12 Aug 2002, Henri Yandell wrote:
>
> >
> > Resolution:
> >
> > I've built a version of the beta with StringUtils having a public
> > constructor. Jason should be testing it out at some point soon to let me
> > know if I screwed up.
> >
> > My reasoning is:
> >
> > 1) I don't want to hold up another project's release wit such a minor
> > issue.
> >
> > 2) I simply replaced the existing beta downloads as I don't believe that
> > this represents a noticable API change. If I'm wrong, please show me
that
> > so I can hang my head in utter dejectedness. [I do have copies of the
old
> > downloads in my home directory, give me an ounce of credit :) ]
>
> In fact this is changed. There is now a commons-lang-1.0-b1.1 release with
> a note on the release page specifying how it's a very tiny change from b1.
> Releasing with a different version is smarter, and means that things like
> Maven can handle the new versioning more easily.
>
> Hopefully that's enough messing around from me :)
>
> Hen
>
>
> --
> 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>
Re: [lang] Action-taken [Was: StringUtils constructor is private]
Posted by Henri Yandell <ba...@generationjava.com>.
On Mon, 12 Aug 2002, Henri Yandell wrote:
>
> Resolution:
>
> I've built a version of the beta with StringUtils having a public
> constructor. Jason should be testing it out at some point soon to let me
> know if I screwed up.
>
> My reasoning is:
>
> 1) I don't want to hold up another project's release wit such a minor
> issue.
>
> 2) I simply replaced the existing beta downloads as I don't believe that
> this represents a noticable API change. If I'm wrong, please show me that
> so I can hang my head in utter dejectedness. [I do have copies of the old
> downloads in my home directory, give me an ounce of credit :) ]
In fact this is changed. There is now a commons-lang-1.0-b1.1 release with
a note on the release page specifying how it's a very tiny change from b1.
Releasing with a different version is smarter, and means that things like
Maven can handle the new versioning more easily.
Hopefully that's enough messing around from me :)
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[lang] Action-taken [Was: StringUtils constructor is private]
Posted by Henri Yandell <ba...@generationjava.com>.
Resolution:
I've built a version of the beta with StringUtils having a public
constructor. Jason should be testing it out at some point soon to let me
know if I screwed up.
My reasoning is:
1) I don't want to hold up another project's release wit such a minor
issue.
2) I simply replaced the existing beta downloads as I don't believe that
this represents a noticable API change. If I'm wrong, please show me that
so I can hang my head in utter dejectedness. [I do have copies of the old
downloads in my home directory, give me an ounce of credit :) ]
I'm happily in the camp that there is no need to have a private
constructor on a Utils class. I'm a believer in only doing the
private-thang when you want to protect something.
On a more generalised note, what is holding us back from making all the
Utils have public constructors as a convention? I know it has a certain
feel of 'well why can't they just call it statically', but Geir's point is
valid, it's not just a Velocity thing but something a small chunk of
projects could conceivably have.
Does the private XxxUtils convention gain us anything? What do we care if
someone makes an instance? It's ugly, but they're choosing the ugly.
[oh, and a sidenote for Jason. [lang] in the title please :) ]
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Steven Caswell wrote:
> I stand corrected on the Velocity issue. I'm still -1 on a public
> constructor because:
>
> a) I believe the developer should be scolded for trying to create an
> instance of a class that clearly is not intended for construction
Scolded? Ha.
This I don't like to hear. If you have a really better alternative
suggest it, but I don't see why if people will use static methods on
instances the sky will fall down, etc, etc.
I don't like it as well, but I don't see any *danger* in it.
If you can show me a concrete example of possible danger, we will all
understand and you will help us all be better programmers.
If not, Velocity just does the most easy thing with the least hassle,
and I don't see the problem.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: StringUtils constructor is private
Posted by Steven Caswell <st...@caswell.name>.
I stand corrected on the Velocity issue. I'm still -1 on a public
constructor because:
a) I believe the developer should be scolded for trying to create an
instance of a class that clearly is not intended for construction and
b) the classes we are discussing are fairly low level, and I'm not
bothered by not being able to subclass.
I'm -0 on a protected constructor. If there is a different solution for
Velocity I'd prefer that approach. What do Velocity users do about all
the other multitudes of classes that don't have a public constructor?
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: dlr@finemaltcoding.com [mailto:dlr@finemaltcoding.com]
> Sent: Monday, August 12, 2002 6:20 PM
> To: Jakarta Commons Developers List
> Cc: steven@caswell.name
> Subject: Re: StringUtils constructor is private
>
>
> "Juozas Baliuka" <ba...@centras.lt> writes:
>
> > Object newInstance(Class clasz){
> > try{
> > Constructor constructor = clasz.getDeclaredConstructor( new
> > Class[] {});
> > constructor.setAccessible(true);
> > return constructor.newInstance( new Object[]{});
>
> No offense intended, but seeing private ctors used like that
> makes me wince. Does anyone have a serious problem with
> providing a protected ctor? There is clearly a valid use
> case for introspection, and though we don't want to promote
> this as the suggested mode of operation, is there really
> enough value in explicitly dis-allowing it (by preventing
> sub-classing)?
> --
>
> Daniel Rall <dl...@finemaltcoding.com>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@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>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Juozas Baliuka" <ba...@centras.lt> writes:
> Object newInstance(Class clasz){
> try{
> Constructor constructor = clasz.getDeclaredConstructor( new Class[]
> {});
> constructor.setAccessible(true);
> return constructor.newInstance( new Object[]{});
No offense intended, but seeing private ctors used like that makes me
wince. Does anyone have a serious problem with providing a protected
ctor? There is clearly a valid use case for introspection, and though
we don't want to promote this as the suggested mode of operation, is
there really enough value in explicitly dis-allowing it (by preventing
sub-classing)?
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by Juozas Baliuka <ba...@centras.lt>.
Hi,
we can add "ReflectUtils" to instantiate objects with private contructor,
something like
this :
Object newInstance(Class clasz){
try{
Constructor constructor = clasz.getDeclaredConstructor( new Class[]
{});
constructor.setAccessible(true);
return constructor.newInstance( new Object[]{});
..............................................................
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Cc: <st...@caswell.name>
Sent: Tuesday, August 13, 2002 12:15 AM
Subject: Re: StringUtils constructor is private
>
>
> On 12 Aug 2002, Daniel Rall wrote:
>
> > Date: 12 Aug 2002 14:30:59 -0700
> > From: Daniel Rall <dl...@finemaltcoding.com>
> > Reply-To: Jakarta Commons Developers List
<co...@jakarta.apache.org>
> > To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> > Cc: steven@caswell.name
> > Subject: Re: StringUtils constructor is private
> >
> > "Steven Caswell" <st...@caswell.name> writes:
> >
> > > I was under the impression that Velocity could not invoke static
> > > methods. If this is true, then creating an instance of StringUtils
would
> > > not do any good. Hence I am -1 on putting in a public constructor
since
> > > it is generally good practice to prevent construction of an instance
of
> > > a class that has no member methods.
> >
> > Velocity will invoke static methods on an instance, just as Java will.
> >
>
> But Velocity apparently *requires* an instance in order to do this,
> whereas Java doesn't.
>
> Call it a restriction instead of a flaw if you want; it's a requirement
> imposed by Velocity on classes whose static methods it wants to access.
>
> Craig
>
>
>
> > --
> > 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>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Craig R. McClanahan" <cr...@apache.org> writes:
> On 12 Aug 2002, Daniel Rall wrote:
>
> > Velocity will invoke static methods on an instance, just as Java will.
>
> But Velocity apparently *requires* an instance in order to do this,
> whereas Java doesn't.
Actually, Java does require an instance to perform introspection
(which was Velocity's original and current default mode of operation).
Note that this differs from vanilla reflection, which is used under
the covers, but is not part of Velocity's "interface".
> Call it a restriction instead of a flaw if you want; it's a requirement
> imposed by Velocity on classes whose static methods it wants to access.
Yes. JavaBean-style introspection doesn't work without an instance to
introspect. IMHO, anyone who wants this Velocity behavior changed
should plug in their own uberspector/introspector combination.
--
Daniel Rall <dl...@finemaltcoding.com>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: StringUtils constructor is private
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On 12 Aug 2002, Daniel Rall wrote:
> Date: 12 Aug 2002 14:30:59 -0700
> From: Daniel Rall <dl...@finemaltcoding.com>
> Reply-To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> To: Jakarta Commons Developers List <co...@jakarta.apache.org>
> Cc: steven@caswell.name
> Subject: Re: StringUtils constructor is private
>
> "Steven Caswell" <st...@caswell.name> writes:
>
> > I was under the impression that Velocity could not invoke static
> > methods. If this is true, then creating an instance of StringUtils would
> > not do any good. Hence I am -1 on putting in a public constructor since
> > it is generally good practice to prevent construction of an instance of
> > a class that has no member methods.
>
> Velocity will invoke static methods on an instance, just as Java will.
>
But Velocity apparently *requires* an instance in order to do this,
whereas Java doesn't.
Call it a restriction instead of a flaw if you want; it's a requirement
imposed by Velocity on classes whose static methods it wants to access.
Craig
> --
> 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>
Re: StringUtils constructor is private
Posted by Daniel Rall <dl...@finemaltcoding.com>.
"Steven Caswell" <st...@caswell.name> writes:
> I was under the impression that Velocity could not invoke static
> methods. If this is true, then creating an instance of StringUtils would
> not do any good. Hence I am -1 on putting in a public constructor since
> it is generally good practice to prevent construction of an instance of
> a class that has no member methods.
Velocity will invoke static methods on an instance, just as Java will.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: StringUtils constructor is private
Posted by Steven Caswell <st...@caswell.name>.
I was under the impression that Velocity could not invoke static
methods. If this is true, then creating an instance of StringUtils would
not do any good. Hence I am -1 on putting in a public constructor since
it is generally good practice to prevent construction of an instance of
a class that has no member methods.
Steven Caswell
steven@caswell.name
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@adeptra.com]
> Sent: Monday, August 12, 2002 9:15 AM
> To: Jakarta Commons Developers List
> Subject: Re: StringUtils constructor is private
>
>
> On 8/12/02 9:37 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
>
> > On Mon, 2002-08-12 at 01:44, Henri Yandell wrote:
> >>
> >> I don't see many reasons why not. I should be able to easily sneak
> >> out a replacement jar for the beta without making a song and dance
> >> about it, it's not something that will break on anyone.
> >>
> >> A bigger question, is why does it break things?
> >
> > We many tools that use velocity that specify a set of tools in
> > properties file. The tools (texen, dvsl, torque) simply instantiate
> > objects for the toolbox based on the contents of a properties file:
> >
> > toolbox.tool.strings = org.apache.commons.lang.StringUtils
> >
> > Which doesn't work with a private constructor.
> >
> >> I'm not a proponent of
> >> privatising constructors without something to protect so am the
> >> easiest person to convince, however if there's some kind of common
> >> tool which can only handle instance methods [and statics by
> >> pretending they're instance] then we should modify all
> Utils to have
> >> constructors unless absolutely necessary.
> >>
> >> Is it a velocity thing?
> >
> > Well people often put utility classes into a velocity context to
> > perform basic string, number manipulation. So in this case,
> yes, it's
> > a velocity thing.
>
> In a sense it's a velocity thing, as Jason is using Velocity
> and coming across the problem.
>
> On the other hand, its a general thing : I think that for
> general utility classes that can be instantiated with an
> argless constructor, having it public makes it easy for any
> 'tool using' code that want to instantiate dynamically
>
> --
> Geir Magnusson Jr.
> Research & Development, Adeptra Inc.
> geirm@adeptra.com
> +1-203-247-1713
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:commons-dev-> unsubscribe@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>
Re: StringUtils constructor is private
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 8/12/02 9:37 AM, "Jason van Zyl" <ja...@zenplex.com> wrote:
> On Mon, 2002-08-12 at 01:44, Henri Yandell wrote:
>>
>> I don't see many reasons why not. I should be able to easily sneak out a
>> replacement jar for the beta without making a song and dance about it,
>> it's not something that will break on anyone.
>>
>> A bigger question, is why does it break things?
>
> We many tools that use velocity that specify a set of tools in
> properties file. The tools (texen, dvsl, torque) simply instantiate
> objects for the toolbox based on the contents of a properties file:
>
> toolbox.tool.strings = org.apache.commons.lang.StringUtils
>
> Which doesn't work with a private constructor.
>
>> I'm not a proponent of
>> privatising constructors without something to protect so am the easiest
>> person to convince, however if there's some kind of common tool which can
>> only handle instance methods [and statics by pretending they're instance]
>> then we should modify all Utils to have constructors unless absolutely
>> necessary.
>>
>> Is it a velocity thing?
>
> Well people often put utility classes into a velocity context to perform
> basic string, number manipulation. So in this case, yes, it's a velocity
> thing.
In a sense it's a velocity thing, as Jason is using Velocity and coming
across the problem.
On the other hand, its a general thing : I think that for general utility
classes that can be instantiated with an argless constructor, having it
public makes it easy for any 'tool using' code that want to instantiate
dynamically
--
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>
Re: StringUtils constructor is private
Posted by Jason van Zyl <ja...@zenplex.com>.
On Mon, 2002-08-12 at 01:44, Henri Yandell wrote:
>
> I don't see many reasons why not. I should be able to easily sneak out a
> replacement jar for the beta without making a song and dance about it,
> it's not something that will break on anyone.
>
> A bigger question, is why does it break things?
We many tools that use velocity that specify a set of tools in
properties file. The tools (texen, dvsl, torque) simply instantiate
objects for the toolbox based on the contents of a properties file:
toolbox.tool.strings = org.apache.commons.lang.StringUtils
Which doesn't work with a private constructor.
> I'm not a proponent of
> privatising constructors without something to protect so am the easiest
> person to convince, however if there's some kind of common tool which can
> only handle instance methods [and statics by pretending they're instance]
> then we should modify all Utils to have constructors unless absolutely
> necessary.
>
> Is it a velocity thing?
Well people often put utility classes into a velocity context to perform
basic string, number manipulation. So in this case, yes, it's a velocity
thing.
> Hen
>
> On 11 Aug 2002, Jason van Zyl wrote:
>
> > Hi,
> >
> > Can this be made public again? I upgrade a ton of things in Maven to use
> > the b1 and it broke things all over the place. I have used
> > StringUtils/Strings for a long time a tool inside a velocity context and
> > the private constructor puts a bit of a damper on this. Can we make this
> > public again?
> >
> > --
> > 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>
> >
> >
>
>
> --
> 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: StringUtils constructor is private
Posted by Henri Yandell <ba...@generationjava.com>.
I don't see many reasons why not. I should be able to easily sneak out a
replacement jar for the beta without making a song and dance about it,
it's not something that will break on anyone.
A bigger question, is why does it break things? I'm not a proponent of
privatising constructors without something to protect so am the easiest
person to convince, however if there's some kind of common tool which can
only handle instance methods [and statics by pretending they're instance]
then we should modify all Utils to have constructors unless absolutely
necessary.
Is it a velocity thing?
Hen
On 11 Aug 2002, Jason van Zyl wrote:
> Hi,
>
> Can this be made public again? I upgrade a ton of things in Maven to use
> the b1 and it broke things all over the place. I have used
> StringUtils/Strings for a long time a tool inside a velocity context and
> the private constructor puts a bit of a damper on this. Can we make this
> public again?
>
> --
> 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>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>