groovy

positional parameters in constructors behaves like a default constructor

Details

  • Type: Sub-task Sub-task
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 1.0-RC-1
  • Fix Version/s: None
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    0

Description

class Foo {
String s
Foo(s)

{ assert s == null this.s = s }

}
def foo = new Foo() // shouldn't call Foo(s) with null!
assert foo
assert !foo.s

See http://www.nabble.com/always-default-constructor--tf2834900.html for more details.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andres Almiray added a comment -

This issue is still around

groovy> class Foo {
groovy>     String s
groovy>     Foo(s) { println "called with s='${s}'!"; this.s = s }
groovy> }
groovy> def foo = new Foo()
groovy> assert foo
groovy> assert !foo.s 

called with s='null'!
Show
Andres Almiray added a comment - This issue is still around groovy> class Foo { groovy> String s groovy> Foo(s) { println "called with s='${s}'!" ; this .s = s } groovy> } groovy> def foo = new Foo() groovy> assert foo groovy> assert !foo.s called with s=' null '!
Hide
Permalink
blackdrag blackdrag added a comment -

I schedule it for 2.0, since the constructor follows the normal method call logic and that logic says for foo() to call foo(s) with s=null if there is no foo() method to call. This is unfortunate and it is bad for performance, but we cannot simply remove that. For the same reason this is no bug, but a improvement now.

Show
blackdrag blackdrag added a comment - I schedule it for 2.0, since the constructor follows the normal method call logic and that logic says for foo() to call foo(s) with s=null if there is no foo() method to call. This is unfortunate and it is bad for performance, but we cannot simply remove that. For the same reason this is no bug, but a improvement now.
Hide
Permalink
blackdrag blackdrag added a comment -

I change this issue to a bug, because on the Groovy Devedloper Conference 2011 we decided we don't want this kind of method call in Groovy 2.0

Show
blackdrag blackdrag added a comment - I change this issue to a bug, because on the Groovy Devedloper Conference 2011 we decided we don't want this kind of method call in Groovy 2.0

People

  • Assignee:
    blackdrag blackdrag
    Reporter:
    Bernd Schiffer
Vote (0)
Watch (2)

Dates

  • Created:
    Updated: