On 06/06/2008, at 12:13 PM, Jochen Theodorou wrote:
I advocate not leaving the spec and get random effects. I guess
what you don't understand is, that there is no ambiguity in
something that is simply not defined. The spec says there is one
setter, the spec does not handle cases with overloaded setters. I
guess you can use a beaninfo class to define the setter which
should be used. so there is possibly a way in the spec to go around
the issue. But that still means that there will be only one setter,
not two (or n). Also atm I am not sure about how to fix that
without breaking for example the way ExpandoMetaClass is used today.
You may say these are technical reasons, but when all the small
gears no longer fit together, then there will be other places where
you do not get what you expect. For example from a user
perspective, why should MetaProperty#getSetter return more than one
method? Or why should it not return a method? Also I see problems
in the class initialization... for example when the beaninfo is
used to set a different method as setter and you define your own
setter then... well, then what? Do I have two setter? They might
have the same signature (because different names), that is very bad.
what do you suggest we do in such a case?
From what Danno and yourself have explained, this seems
unresolvable. If that's the spec and it must be adhered to then this
is just impossible.
What is left to do though is to _clearly_ define what Groovy will do
in the situation where multiple potential setters are defined and one
is not explicitly declared as the setter. This seems to be a bit gray.
LD.
15 messages in org.codehaus.groovy.userRe: [groovy-user] Setter overloading ...
