commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [clazz] draft reflect implementation
Date Mon, 18 Nov 2002 22:54:32 GMT
From: "Dmitri Plotnikov" <>
> > - will it handle the case of defining
> >  int getAge()
> >  void setAge(String age)
> >  void setAge(int age)
> Currently it will reject this property altogether as having to
> accessors. What should it do?  And generally speaking, how do we
> justify our choices in how methods are mapped to properties?  Do you
> think we have the authority to introduce some kind of a "standard"?
> Taking into account the customizability of clazz, I believe we might.
> Thus, why not simply decide what we are going to do by default in all
> these cases by voting?  For example, in the above case we probably have
> three reasonable solutions:
> 1. Reject the methods as conflicting
> 2. Accept the setAge(int) method as the getter and ignore
> setAge(String)
> 3. Accept them both and decide dynamically which one to call based on
> the type (and perhaps converability) of the value.

We may have to have an java Introspector compatable mode, to enable [clazz]
to plugin to projects currently using the Introspector. However, lets
concentrate on the sensible approach moving forward at the moment.

If we can get to having a Property with a primary readMethod plus a list of
secondaries, then #3 above becomes possible.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message