15 messages in org.codehaus.groovy.userRe: [groovy-user] Setter overloading ...
FromSent OnAttachments
Marc PalmerJun 4, 2008 7:08 am 
Jochen TheodorouJun 4, 2008 9:01 am 
Luke DaleyJun 4, 2008 3:44 pm 
Marc PalmerJun 5, 2008 2:57 am 
Jochen TheodorouJun 5, 2008 3:32 am 
Jochen TheodorouJun 5, 2008 3:43 am 
Luke DaleyJun 5, 2008 4:51 pm 
Danno FerrinJun 5, 2008 6:24 pm 
Jochen TheodorouJun 5, 2008 7:12 pm 
Luke DaleyJun 5, 2008 7:52 pm 
Luke DaleyJun 5, 2008 8:48 pm 
Michael S. JessopJun 5, 2008 9:49 pm 
Jochen TheodorouJun 6, 2008 4:03 am 
Danno FerrinJun 6, 2008 5:25 am 
Danno FerrinJun 6, 2008 5:28 am 
Actions with this message:
Paste this link in email or IM:
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 3:32:03 am
List:org.codehaus.groovy.user

Luke Daley schrieb:

On 05/06/2008, at 2:02 AM, Jochen Theodorou wrote:

Marc Palmer schrieb:

Hi, Should setter overloading work? I'm extending a java class that provides: void setDuration(Duration d) { .. } ...in my groovy class extending it: class EnhancediTunesEntryInformationImpl extends EntryInformationImpl { void setDuration(String s) { super.setDuration(new Duration(s)) } } ...this fails with groovy complaining that it cannot cast the string to Duration. If I change my setter to: void setDurationText(String s) { super.setDuration(new Duration(s)) } it works fine. So... should overloaded setters resolve with property access or not? I'm just trying to establish whether or not there is a bug to isolate here.

The problem here is the bean specification. remember that when you do foo.duration = "...", then you try to set a property named duration with a string. Now the Bean spec knows only one setter and getter. And since you do overload and not overwrite you end up with two of them. That's a problem since Groovy expects, according to the spec, only of them. If you do foo.setDuration(""), then there shouldn't be a problem at all.

It's not clear from your statements Jochen whether this is something that doesn't work now and may in the future, or for some technical reason can never work. In my opinion, this _is_ an issue as it is not what you would expect. It's reasonable to assume that setting a property like this would call the right setter. This assumption caused a bug for me that was very nasty and hard to track down.

If it's something that just doesn't work now please say so so a ticket can be raised.

first, it is out of the specification, so it might work or might not. We use the Java standard mechanism very much here to get this property information. Since your code has multiple setters Java will in some cases select one method in other cases probably the other method. I can not say it works or works not, I can not even say it should work or it should not. For example I tested it locally on 1.6 and it worked there. Strictly if we don't want to change MetaProperty, then we can not make it working, since there is one getter and one setter (following the bean spec) and you have already two setter methods. That means, either the property information becomes useless or we make a breaking change here that might affect many.

so is it a bug? No. At maximum it is an improvement, an extension to the bean spec for example. But it also means we have to rework some MOP classes and that means it won't be there before 2.0. So you can make a JIRA entry for this, but please don't expect this to be implemented in the next version

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:

http://xircles.codehaus.org/manage_email