 | 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 5, 2008 6:24:39 pm | |
| List: | org.codehaus.groovy.user | |
On Thu, Jun 5, 2008 at 5:52 PM, Luke Daley <ld...@ldaley.com> wrote:
On 05/06/2008, at 8:44 PM, Jochen Theodorou wrote:
The fact that groovy turns x.duration = y into x.setDuration(y) for me
means that Groovy should definitely use normal method resolution.
well, that is wrong. Groovy does not simply turn it into a method call. It might result in that method call, but there is a major difference between these. First Groovy asks for that property in the MetaClass, and in this case a property is returned, which means its setter method is called. that means that normally no Groovy standard method call would happen here. Allowing overloaded setters currently means, that we have to do a full method selection each time the property is called. Additionally the information stored in the MetaProperty becomes simply wrong then, because it contains only one method, not both. Maybe you don't remember that by changing the information in the MetaProperty you can turn x.duration =y into x.foo(y).... meaning you could have a setter of any name... and not only that, you can even change the object, that is used to make the call on. While I think the last is not supported by the bean spec, I think the usage of other methods as setter (or getter) is supported by providing a bean info class.
I don't really see any of this as being to the point. How Groovy implements this really does not matter to me. As Marc said, the principle of least surprise leads you to expect this to work. Unless there is a very good reason why this can't work, it should.
The principal of least surprise depends on who you talk to. As someone who is familiar with the JavaBeans spec and the claim that Groovy simplifies JavaBeans properties I would be suprised (nay, astonished) if I called x.y=1 where y is a double and groovy decided to call the int (or BigInteger) varient because it happens to be an int, or float, or whatever else.
The issue isn't that Groovy converts it into x.setY(1), but that groovy calls the setter method for property y that JavaBeans API tells it to call when introspected. (Note: introspected, not reflected). The spec could be set up so that the setter for property y could be a method called 'quackQuack' as long as the type signatures are conformant. What is usually seen is that the spec specified a get/set fallback and auto-reflection to that pattern when an appropriate BeanInfo class is not present. The default MetaClass infrastructure inside of Groovy asks for the BeanInfo to set it's getter and setter methods, so the JavaBeans infrastructure is used direcly by Groovy. The auto reflector gets confused when there is an overloaded setter, so that is bad practice WRT the JavaBeans spec.
The spec also has no allowance for multiple setter methods, so I would consider any such support a deviation from the spec.
So far you seemed to have side stepped that issue and focussed on more technical considerations.
The technical issues in this case are paramount. It's not that it cannot be done, but that it shouldn't be done.
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?
The causual user or the user who wants a Java platform compilant experience?
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?
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?
Setting a property and calling a method are two different things semantically. Usually they are the same thing in effect, but this is the case where they are not.
If it's something that just doesn't work now please say so so a ticket can
be raised.
I agree - is this technically feasible, if so can we JIRA it for 2.0?
for 2.0, yes.. only the ability to use exactly one setter for a property might be lost with this.
IMHO this should be closed as a 'won't fix,' but I'll leave it to the more senior committers to make that call.
------------------------------------------------------ I'm Danno Ferrin, and I approved this message.