Quoting robert burrell donkin <[EMAIL PROTECTED]>:
>
> 1+2 it seemed clear that craig intended no constructors to be available
> (and he usually has good reasons for his design decisions) but i think
> that allowing WrapDynaClass and WrapDynaBean to fit better into
> DynaBean frameworks seems like a strong argument for providing this
> functionality. unless someone else speaks up, i'll likely commit
> something along these lines.
>
This design was indeed deliberate. Whether it makes sense is certainly open to
discussion :-).
The design intent for WrapDynaBean{,Class} was that you'd create new
WrapDynaBean instances by saying:
Object aJavaBean = ...;
DynaBean db = new WrapDynaBean(aJavaBean);
which (if it hasn't been done already) causes a WrapDynaBeanClass instance to be
created for you ... 1:1 with the underlying Class instance. I don't see a
compelling need for making the WrapDynaBeanClass constructor public, but
wouldn't be opposed to that if there was a good use case.
For WrapDynaClass.newInstance(), though, it doesn't make sense to ask for a new
instance of WrapDynaBean without having it already wrapping some real bean --
and there's no way to specify one without a new method signature on newInstance
that passes in the bean to be wrapped. Doesn't that tie you very closely to
this particular implementation of DynaBean?
Same argument applies to WrapDynaBean.getInstance() -- I'm not strongly opposed
to that, but my thinking was, once you've made the effort to wrap it, you'd be
using DynaBean APIs from now forward in any applications that actually use
these beans. If you tie yourself to explicitly to the WrapDynaBean (instead of
the generic DynaBean) contract, doesn't that prevent you from switching
DynaBean implementations later on if you find something better/faster?
> 3 seems to me to be a symptom of a bigger issue (which has been known
> for some time). the exception handling in beanutils is painful and
> confusing to many users. i'd be very reluctant to break backwards
> compatibility (even for symantics) and i suspect that the proposed
> patch does. we've talked before about the possibility of factoring out
> the exception handling and possible it might be better to fix this
> rather than the symptom. so maybe a little more talk and thought is
> needed about this one.
>
I'm on general principles opposed to breaking backward compatibility on method
names -- but I don't have any problem with efficiency improvements, or
usability improvements (i.e. error messages that point you at what the real
issue is). I haven't had time to look at your patch yet (slightly busy with
JavaServer Faces at the moment ;-), but agree with Robert's general point that
an overall review of how BeanUtils is put together as a whole is probably
overdue. Indeed, that sort of thing would make sense in the context of a
BeanUtils 2.0 type discussion, perhaps having 2.x releases while we continue
bugfixes on the 1.x track and keep compatibility there.
BeanUtils is a very widely used package, so we have to be even more careful than
is typical in j-c about compatibility. But it's also time to do some
innovation again, and these sorts of discussions might be a good kickoff for
that.
> comments welcome
>
> - robert
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
