On Wednesday, July 30, 2003, at 06:08 PM, Gary Gregory wrote:
We have here been moving away from singletons. When some logic needs to do
something with one of our util classes, it does it the OO way: create and
configure an object and call instance methods. When you're done, toss the
object and
> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: 30 July 2003 18:39
> To: Jakarta Commons Developers List
> Subject: RE: [io][vote] FileUtils: decision on style
>
> > Preventing people who don't know what they are doing from ma
om: Arun Thomas [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, July 30, 2003 09:16
> To: Jakarta Commons Developers List; [EMAIL PROTECTED]
> Subject: RE: [io][vote] FileUtils: decision on style
>
> David,
>
> Keep in mind that the discussion is in the context of static
--- "Hope, Matthew" <[EMAIL PROTECTED]> wrote:
> > There's at least one person in this discussion who needs to extend the
> > utils classes so it doesn't make sense to declare the classes
> > final. How
> > does it benefit anyone by declaring a reusable library
> > class/method final?
>
> Preve
03 09:16
To: Jakarta Commons Developers List; [EMAIL PROTECTED]
Subject: RE: [io][vote] FileUtils: decision on style
David,
Keep in mind that the discussion is in the context of static methods, not
instance methods. Gary pointed out that there is a significant difference
between instance and s
> There's at least one person in this discussion who needs to extend the
> utils classes so it doesn't make sense to declare the classes
> final. How
> does it benefit anyone by declaring a reusable library
> class/method final?
Preventing people who don't know what they are doing from making m
David
>
> -AMT
>
> -Original Message-
> From: David Graham [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 29, 2003 6:48 PM
> To: Jakarta Commons Developers List
> Subject: RE: [io][vote] FileUtils: decision on style
>
>
> --- Neil O'Toole <[EMAIL
On Wed, 30 Jul 2003, Arun Thomas wrote:
> However, while we're discussing only classes which package together
> static methods - does allowing extensibility make sense?
That's exactly the position beanutils was in (BeanUtils, PropertyUtils,
and ConvertUtils were 100% static utility methods). W
mmons Developers List
Subject: RE: [io][vote] FileUtils: decision on style
--- Neil O'Toole <[EMAIL PROTECTED]> wrote:
> > At first glance I don't really see the `need to override behavior'
> > argument -- if a user doesn't like the way a static method is
> >
If others can't deal with private constructors, then I guess there isn't
a choice.
But in theory, I think protected constructors would be the best since
they would allow the constructor to be accessible to subclasses, if
necessary.
On Tue, 2003-07-29 at 05:53, Jeremias Maerki wrote:
> On 29.
> > this
> > topic? At first glance I don't really see the `need to override
> > behavior'
> > argument -- if a user doesn't like the way a static method is
> > implemented, can't they just implement their own in a separate class?
> >
> >
egation to the original method where
appropriate.
Cheers,
-AMT
-Original Message-
From: Neil O'Toole [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 3:16 PM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style
> At first glance I do
CTED]
Sent: Tuesday, July 29, 2003 12:30 PM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style
--- Arun Thomas <[EMAIL PROTECTED]> wrote:
> Hmmm From the last three notes - I think I understand clearly the
> motivation for requiring the
digging on
> this
> topic? At first glance I don't really see the `need to override
> behavior'
> argument -- if a user doesn't like the way a static method is
> implemented, can't they just implement their own in a separate class?
>
> michael
--- Henri Yandell <[EMAIL PROTECTED]> wrote:
>
>
> On Tue, 29 Jul 2003, David Graham wrote:
>
> > --- Arun Thomas <[EMAIL PROTECTED]> wrote:
> > > Hmmm From the last three notes - I think I understand clearly
> the
> > > motivation for requiring the public no-arg constructor, but I still
>
ke.
David
>
>michael
>
>
> >
> > David
> >
> > >
> > > Cheers,
> > > -AMT
> > >
> > > -Original Message-
> > > From: David Graham [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, July 29,
hael
>
> David
>
> >
> > Cheers,
> > -AMT
> >
> > -Original Message-----
> > From: David Graham [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, July 29, 2003 11:44 AM
> > To: Jakarta Commons Developers List
> > Subject: RE: [io][vote] FileUti
On Tue, 29 Jul 2003, David Graham wrote:
> --- Arun Thomas <[EMAIL PROTECTED]> wrote:
> > Hmmm From the last three notes - I think I understand clearly the
> > motivation for requiring the public no-arg constructor, but I still
> > don't understand the reasoning behind the need for avoiding
ent: Tuesday, July 29, 2003 11:44 AM
> To: Jakarta Commons Developers List
> Subject: RE: [io][vote] FileUtils: decision on style
>
>
> --- Arun Thomas <[EMAIL PROTECTED]> wrote:
> > Can someone expound on this "lesson"? The Developers Guide mentions
> >
tatic methods?
Cheers,
-AMT
-Original Message-
From: David Graham [mailto:[EMAIL PROTECTED]
Sent: Tuesday, July 29, 2003 11:44 AM
To: Jakarta Commons Developers List
Subject: RE: [io][vote] FileUtils: decision on style
--- Arun Thomas <[EMAIL PROTECTED]> wrote:
> Can someone e
On Tue, 29 Jul 2003 [EMAIL PROTECTED] wrote:
> Hey thanks for the heads up!
>
> being one of the original authors/contributor of this class, I do
> have some comments (mostly in favour of your proposal)...
>
> 1rst: you seem to have added a private constructor to prevent
> instantiation, which h
On 29.07.2003 10:20:00 Christoph.Reck wrote:
> Hey thanks for the heads up!
>
> being one of the original authors/contributor of this class, I do
> have some comments (mostly in favour of your proposal)...
>
> 1rst: you seem to have added a private constructor to prevent
> instantiation, which h
Hey thanks for the heads up!
being one of the original authors/contributor of this class, I do
have some comments (mostly in favour of your proposal)...
1rst: you seem to have added a private constructor to prevent
instantiation, which hurts usage as in velocity, where you need
an instance of a cl
In FileUtils we currently have many duplicate method due to merging
classes from several sources. For example, there is a extension(String)
and getExtension(String) method.
(Ironically, both have the same bug: "/tmp/foo.bar/README" evaluates to
"bar/README".)
So, we have to decide how these met
24 matches
Mail list logo
