--- On Sat, 3/14/09, Gary Gregory <ggreg...@seagullsoftware.com> wrote:
> From: Gary Gregory <ggreg...@seagullsoftware.com>
> Subject: RE: [lang] 3.0, what's in; what's out
> To: "Commons Developers List" <dev@commons.apache.org>
> Date: Saturday, March 14, 2009, 2:39 PM
> > -----Original Message-----
> > From: Matt Benson [mailto:gudnabr...@yahoo.com]
> > Sent: Saturday, March 14, 2009 12:36 PM
> > To: Commons Developers List
> > Subject: RE: [lang] 3.0, what's in; what's out
> >
> >
> > --- On Sat, 3/14/09, Gary Gregory <ggreg...@seagullsoftware.com>
> wrote:
> >
> > > From: Gary Gregory <ggreg...@seagullsoftware.com>
> > > Subject: RE: [lang] 3.0, what's in; what's out
> > > To: "Commons Developers List" <dev@commons.apache.org>
> > > Date: Saturday, March 14, 2009, 2:19 PM
> > > > -----Original Message-----
> > > > From: Matt Benson [mailto:gudnabr...@yahoo.com]
> > > > Sent: Saturday, March 14, 2009 11:57 AM
> > > > To: Commons Developers List
> > > > Subject: Re: [lang] 3.0, what's in; what's
> out
> > > >
> > > >
> > > > I'd like to add a TypeUtils to the reflect
> subpackage,
> > > to provide as much
> > > > help as possible for discovering type
> parameters of
> > > generic types. I
> > >
> > > I thought that type erasure made this impossible?
> Can you
> > > define what the class would do please?
> >
> > Based on the research I have done thus far, type
> erasure makes it
> > impossible to determine the parameters of a given
> object, but you can
> > still learn certain things about type parameters of
> methods, fields, and
> > superclasses that may be helpful. The idea is
> under development, but it's
> > based on James's code from [proxy]'s 2.0 branch.
> Thanks for your concern
> > though! ;)
>
> Thanks for the clarification. BTW, I've you have not read
> it yet, this is a great resource:
> http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html
>
I keep this tutorial open a lot of the time! ;) I even dropped her a note
thanking her for it.
-Matt
> Gary
>
> >
> > -Matt
> >
> > >
> > > Thanks,
> > > Gary
> > >
> > > > recently commented in ClassUtils that a
> 3.0,
> > > Java5-compatible assignable
> > > > test should assume autoboxing == true (since
> one would
> > > think the
> > > > assignable test would normally be used in
> preparation
> > > for e.g. a
> > > > reflection-based method call autoboxing
> should have
> > > been a safe assumption
> > > > to begin with, but anyway...).
> > > >
> > > > -Matt
> > > >
> > > > --- On Sat, 3/14/09, Henri Yandell <flame...@gmail.com>
> > > wrote:
> > > >
> > > > > From: Henri Yandell <flame...@gmail.com>
> > > > > Subject: [lang] 3.0, what's in; what's
> out
> > > > > To: "Commons Developers List" <dev@commons.apache.org>
> > > > > Date: Saturday, March 14, 2009, 4:21
> AM
> > > > > Starting up a thread for cleanup
> > > > > discussions on Lang.
> > > > >
> > > > > I've removed the enum (was a blocker on
> JDK 5)
> > > and enums
> > > > > (people need
> > > > > to use real enums now) packages from
> Lang's trunk
> > > and moved
> > > > > them to a
> > > > > lang-backcompat sibling component. I've
> not made
> > > it a
> > > > > branch, it lives
> > > > > at the same level as trunk and will
> need its
> > > future to be
> > > > > decided.
> > > > >
> > > > > An EnumUtils class has been added to
> the main
> > > lang
> > > > > package.
> > > > >
> > > > > I also think the exception package
> should go.
> > > Again - the
> > > > > JDK has
> > > > > support for this now and there's no
> strong value
> > > in Lang
> > > > > having an
> > > > > alternative to stop people thinking
> about JDK
> > > 1.5. The
> > > > > ExceptionUtils
> > > > > class should move up to the main lang
> package and
> > > needs to
> > > > > have the
> > > > > Nestable Lang code removed from it.
> Presumably it
> > > still has
> > > > > value.
> > > > >
> > > > > Some of the Date code is tempting to
> delete.
> > > Either due to
> > > > > buginess,
> > > > > or general 'this isn't that cool'
> ness.
> > > > >
> > > > > JVMRandom should go. I'm not convinced
> it's had
> > > much use.
> > > > >
> > > > > IDKey should move to package scoping -
> I've not
> > > seen an
> > > > > argument made
> > > > > yet for it being public.
> > > > >
> > > > > Fraction is up for debate. Do we cede
> this to
> > > Commons Math.
> > > > > Sure it
> > > > > might add another jar to some people's
> code, but
> > > probably
> > > > > good for
> > > > > them to be more aware of Math.
> > > > >
> > > > > WordUtils and StringEscapeUtils both
> strike me
> > > as
> > > > > 'desirable but
> > > > > flawed'. We should consider overhauls.
> > > > >
> > > > > The Security requiring stuff in builder
> for
> > > reflection
> > > > > needs to go
> > > > > away imo. Makes it less than useful.
> > > > >
> > > > > We need a PackageUtils in reflect.
> > > > >
> > > > > We need to consider if there are any
> annotations
> > > that are
> > > > > valuable to
> > > > > be pseudo-standard.
> > > > >
> > > > > I'm still partial to a RegexUtils.
> > > > >
> > > > > Plus general generifying, varargs,
> autoboxing.
> > > > >
> > > > > Deletion of all deprecated
> methods/classes.
> > > > >
> > > > > And the various other backwards
> incompatible
> > > changes that
> > > > > people have
> > > > > been requesting.
> > > > >
> > > > > Hen
> > > > >
> > > > >
> > >
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > > For additional commands, e-mail: dev-h...@commons.apache.org
> > >
> > >
> >
> >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
