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 Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.0-RC-1
    • Fix Version/s: None
    • Component/s: groovy-runtime
    • 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

        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
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: