Groovy
  1. Groovy
  2. GROOVY-2503 MOP 2.0 design inflluencing issues
  3. GROOVY-1603

positional parameters in constructors behaves like a default constructor

    Details

    • Type: Sub-task Sub-task
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0-RC-1
    • Fix Version/s: None
    • Component/s: groovy-runtime
    • Labels:
      None

      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

        Hide
        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
        Jochen Theodorou 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
        Jochen Theodorou 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
        Jochen Theodorou 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
        Jochen Theodorou 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:
            Unassigned
            Reporter:
            Bernd Schiffer
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development