 | 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: | Jochen Theodorou (blac...@gmx.org) | |
| Date: | Jun 5, 2008 7:12:51 pm | |
| List: | org.codehaus.groovy.user | |
Luke Daley schrieb:
[...]
So far you seemed to have side stepped that issue and focussed on more technical considerations.
I was asked for technical considerations.
properties are not method calls. They are different in definition and their path in the MOP is different.
And the relevance for the user is?
that they are not the same and to expect they work the same is wrong.
With my Java beans oriented head on I still see it like a problem, because the classes used to access the beans don't expect such things from you and may select a random setter.
Isn't that beside the point?
depends. If you say Groovy should do what you expect, then it surely is. If you say Groovy should follow the spec, then it is not. BTW, your case worked for me in 1.6
You actually advocated calling the second setter explicitly as a method, so how does this avoid the ambiguity in the spec you are referring to?
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?
bye blackdrag
-- Jochen "blackdrag" Theodorou The Groovy Project Tech Lead (http://groovy.codehaus.org) http://blackdragsview.blogspot.com/ http://www.g2one.com/
--------------------------------------------------------------------- To unsubscribe from this list, please visit: