groovy

Assignment calls the wrong setter, depending on order of declaration

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.5.1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Environment:
    Windows XP, java 6 update 4, ant 1.7, groovy 1.6 beta 1
  • Number of attachments :
    0

Description

The following build.xml fails:

<?xml version="1.0" encoding="UTF-8"?>
<project name="test" default="run">

	<path id="groovy.classpath">
		<fileset dir="." includes="groovy-*.jar"/>
	</path>

	<taskdef name="groovy" classname="org.codehaus.groovy.ant.Groovy" classpathref="groovy.classpath"/>

	<target name="compile">
		<echo file="Test.java">
			public class Test
			{
				public void setField( String value )
				{ 
					System.out.println( "String" );
				}
			
				public void setField( Integer value )
				{ 
					System.out.println( "Integer" );
				}
			}
		</echo>
		<javac srcdir="." includes="Test.java"/>
	</target>

	<target name="run" depends="compile">
		<groovy>
			try
			{
				new Test().setField( "sss" ) // This works
				println "success 1"
				new Test().field = "sss" // This gives exception
				println "success 2"
			}
			catch( Exception e )
			{
				e.printStackTrace( System.out )
			}
		</groovy>
	</target>

</project>

(you need to put the groovy.jar in the same folder)

The setField() succeeds, but the assignment fails.

If I change the order of the two setField() methods, both succeed.

Issue Links

is depended upon by

Task - A task that needs to be done. GROOVY-2503 MOP 2.0 design inflluencing issues

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.
is duplicated by

Sub-task - The sub-task of the issue GROOVY-2049 Provide some auto-overloading between int and String values

  • Major - Major loss of function.
  • Open - The issue is open and ready for the assignee to start work on it.

Bug - A problem which impairs or prevents the functions of the product. GROOVY-3632 Cannot overload/override setter with mutliple methods

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
René de Bloois added a comment -

Sorry, by accident I did select the 'fix version' instead of the 'affects version'.

Show
René de Bloois added a comment - Sorry, by accident I did select the 'fix version' instead of the 'affects version'.
Hide
Permalink
Danno Ferrin added a comment -

I'll let Jochen or one of the other code compiler committers make the final call, but my vote is to close as "won't fix".

The real problem comes in with the JavaBeans spec. It only has a defined and reliable behavior (in the absense of BeanInfos) when there is only one set<foo> method for a property. The property shortcut is a function of JavaBeans, so any violation of JavaBeans should also result in a failure for Groovy.

Show
Danno Ferrin added a comment - I'll let Jochen or one of the other code compiler committers make the final call, but my vote is to close as "won't fix". The real problem comes in with the JavaBeans spec. It only has a defined and reliable behavior (in the absense of BeanInfos) when there is only one set<foo> method for a property. The property shortcut is a function of JavaBeans, so any violation of JavaBeans should also result in a failure for Groovy.
Hide
Permalink
René de Bloois added a comment -

If that's the case that would be unfortunate.

Personally, in groovy I would expect the setter to be equivalent to an assignment, because of the operator overloading that Groovy has. A setter seems to be nothing more than an overloaded field assignment. But that is my first impression. I don't know if this would give any conceptual problems besides the existing technical problems.

With all the reflection going on in the groovy runtime, isn't it already possible to do it like that?

And if it is not possible, than I think that this issue should be transformed to "unpredictable behaviour when doing assignment with overloaded setters". I think it should always fail, independent of the declaration order of the setters. (it took me 2 or 3 hours to figure this problem out, developers should be protected against this).

Show
René de Bloois added a comment - If that's the case that would be unfortunate. Personally, in groovy I would expect the setter to be equivalent to an assignment, because of the operator overloading that Groovy has. A setter seems to be nothing more than an overloaded field assignment. But that is my first impression. I don't know if this would give any conceptual problems besides the existing technical problems. With all the reflection going on in the groovy runtime, isn't it already possible to do it like that? And if it is not possible, than I think that this issue should be transformed to "unpredictable behaviour when doing assignment with overloaded setters". I think it should always fail, independent of the declaration order of the setters. (it took me 2 or 3 hours to figure this problem out, developers should be protected against this).
Hide
Permalink
blackdrag blackdrag added a comment -

I changed the fix version and affect version and the priority. It is not a critical bug, because the foo.bar shortcut is thought for beans or something that looks at last partially like a bean, but a overloaded setter is not part of the bean specification. So basically Groovy is not doing anything wrong. As I see it the currentty MOP does not give that functionality away that you would need. we could for example invoke the method by the MetaClass... that would be a small change internally, but the effects might be very big on the outside. And it opens new problem, like for example if missingMethod should be invoked or not... something we decided against for normal properties. But especially in a MetaClass like EMC it might have side effects, that we can't yet foresee.. so I would like to make this part of the 2.0 MOP

Show
blackdrag blackdrag added a comment - I changed the fix version and affect version and the priority. It is not a critical bug, because the foo.bar shortcut is thought for beans or something that looks at last partially like a bean, but a overloaded setter is not part of the bean specification. So basically Groovy is not doing anything wrong. As I see it the currentty MOP does not give that functionality away that you would need. we could for example invoke the method by the MetaClass... that would be a small change internally, but the effects might be very big on the outside. And it opens new problem, like for example if missingMethod should be invoked or not... something we decided against for normal properties. But especially in a MetaClass like EMC it might have side effects, that we can't yet foresee.. so I would like to make this part of the 2.0 MOP

People

  • Assignee:
    Unassigned
    Reporter:
    René de Bloois
Vote (2)
Watch (2)

Dates

  • Created:
    Updated: