On Thursday, December 5, 2002, at 10:49 PM, Costin Manolache wrote:
I'm not sure I understand what is proposed :-)
it's the same old proposal. discussed at length a long time ago. have only
one canonical set of basic reflection code that's easy to maintain and bug
fix.
However I'm strongly -
I'm not sure I understand what is proposed :-)
However I'm strongly -1 on removing ( or deprecating ) public
code in beanutils, or on adding more dependencies.
It works fine and if another package wants to do reflection - that's
perfectly fine, but that doesn't mean everyone else is required to
s
On Thu, 5 Dec 2002, robert burrell donkin wrote:
> i only threatened to -1 after trying quite a few times to get rodney to
> discuss his commit.
I'm not interested in starting some sort of flame war on this minor point,
but for the record, I saw exactly two emails on this--one directly to my
apac
--- robert burrell donkin
<[EMAIL PROTECTED]> wrote:
> On Thursday, December 5, 2002, at 07:20 PM, Morgan
> Delagrange wrote:
>
> > So it seems like the point is not
> "ConstructorUtils in
> > beanutils: a bad idea", but rather "Reflection
> classes
> > in beanutils: a bad idea". It's inappropr
On Thursday, December 5, 2002, at 07:20 PM, Morgan Delagrange wrote:
So it seems like the point is not "ConstructorUtils in
beanutils: a bad idea", but rather "Reflection classes
in beanutils: a bad idea". It's inappropriate to -1
adding ConstructorUtils to beanutils on the basis of
scope, sinc
So it seems like the point is not "ConstructorUtils in
beanutils: a bad idea", but rather "Reflection classes
in beanutils: a bad idea". It's inappropriate to -1
adding ConstructorUtils to beanutils on the basis of
scope, since that is where such classes currently
belong. If you want to move ref
On Thursday, December 5, 2002, at 03:25 PM, Rodney Waldhoff wrote:
Looking through the archives, I now see the thread named
"[beanutils][lang][PROPOSAL] deprecated beanutils version of MethodUtils"
[1] which apparently should have been flagged "[VOTE]", if that was
intended to be a binding vote
I did recall seeing some threads around lang/beanutils/reflection/clazz,
indeed before I wrote ConstructorUtils I checked those places for the
functionality I was looking for. Lang's ConstructorUtil class wasn't quite
it, and the last commit message reads "[...] (not all working)", which
wasn't exa
>
> Subject: Re: [beanutils] ConstructorUtils in beanutils: a bad idea
>
> On Wed, 4 Dec 2002, robert burrell donkin wrote:
>
> >
> > i really think that lang is the right place for this [ConstructorUtils].
> > are there any good reasons why it needs to be in beanutils?
>
On Wed, 4 Dec 2002, robert burrell donkin wrote:
>
> i really think that lang is the right place for this [ConstructorUtils].
> are there any good reasons why it needs to be in beanutils?
>
I disagree that ConstructorUtils belongs in lang, or more accurately, I
believe it is a better fit for bean
10 matches
Mail list logo
