 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
15 messages in org.codehaus.groovy.userRe: [groovy-user] Setter overloading ...| From | Sent On | Attachments |
|---|---|---|
| Marc Palmer | Jun 4, 2008 7:08 am | |
| Jochen Theodorou | Jun 4, 2008 9:01 am | |
| Luke Daley | Jun 4, 2008 3:44 pm | |
| Marc Palmer | Jun 5, 2008 2:57 am | |
| Jochen Theodorou | Jun 5, 2008 3:32 am | |
| Jochen Theodorou | Jun 5, 2008 3:43 am | |
| Luke Daley | Jun 5, 2008 4:51 pm | |
| Danno Ferrin | Jun 5, 2008 6:24 pm | |
| Jochen Theodorou | Jun 5, 2008 7:12 pm | |
| Luke Daley | Jun 5, 2008 7:52 pm | |
| Luke Daley | Jun 5, 2008 8:48 pm | |
| Michael S. Jessop | Jun 5, 2008 9:49 pm | |
| Jochen Theodorou | Jun 6, 2008 4:03 am | |
| Danno Ferrin | Jun 6, 2008 5:25 am | |
| Danno Ferrin | Jun 6, 2008 5:28 am |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [groovy-user] Setter overloading - should it work? | Actions... |
|---|---|---|
| From: | Danno Ferrin (dann...@shemnon.com) | |
| Date: | Jun 6, 2008 5:28:20 am | |
| List: | org.codehaus.groovy.user | |
On Thu, Jun 5, 2008 at 8:52 PM, Luke Daley <ld...@ldaley.com> wrote:
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.
It is clearly defned. Use the BeanInfo. Since all methods with a correct type signature could conceivably be a potential setter, we should use the one the BeanInfo tells us to use. That java.beans.Introspector gets confused when multiple setter patterns exist is a problem for the core platform, and a practice that is generally discouraged as a result. But it is not a groovy issue, but an issue for the JCP.
--Danno
------------------------------------------------------ I'm Danno Ferrin, and I approved this message.