object initializer

[Jochen Theodorou]

as we have static intializers in classes I thought I should add object
initializers too. They are recognized by the grammar already, just not
implemented. So I implemented the needed code and wrote a test

class Foo {
     def bar = 1
     { bar = 2 }
}

def f = new Foo()
assert f.bar==2


now this doesn't work, because the grammar thinks, the code in brackets
is part of a closure called on an Integer! It is ok, if I put an ";"
after the 1

class Foo {
     def bar = 1;
     { bar = 2 }
}

def f = new Foo()
assert f.bar==2


so what should we do? I am unsure if I am able to recognize this case
somehow and give a more meaningfull error message. foridding calls to
closures outside methods doesn't look like a good way to me too.
Removing the initializer completly is another option, but then we should
remove it from the grammar as well.

comments?

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Ray Cromwell]

Actually, this would be a nice addition that would bring Groovy closer
to Ruby metaprogramming capabilties. A typical Ruby example (disclosure:
I am not a Ruby programmer, just interested in the language) looks like this

class Monster
   traits :armor, :life, :mana, :stamina
end

class Dragon < Monster
   armor 20
   life 10
   mana 30
   stamina 90
end

"traits" is a meta method that injects the properties armor, life, mana,
and stamina, along with getter and setter during initialization.

Here's my half-hearted groovy attempt


class Monster extends Expando
{
   def values = [:]
   def traits(Object[] args)
   {
     args.each
     { it ->
       values[it]="";
       setProperty(it,
           { val -> if(val)
                    { values[it]=val; }
                    else
                    { return values[it]; }
           })
     }
   }

   Monster()
   {
        traits "armor", "life", "mana", "stamina"
   }
}


class Dragon extends Monster
{
    Dragon() {

      armor 20
      life 10
      mana 30
      stamina 90

    }
}

def d = new Dragon()
print "Dragon has " + d.life() +" life left."

Clearly two things would make this cleaner.

1) support for Symbols in Groovy. I kinda like #armor, #life, #mana,
#stamina.

2) the ability to have initialization expressions

Could the grammar support a naked expression in the class definition?

clearly

class Foo
{
   def x = new HashMap()
}

is an initializer

but why not

class Foo
{
   blah()
   bar()
   baz()
}

being interpreted as three initialization calls. Otherwise, may as well
put them in the constructor.

-Ray


Jochen Theodorou wrote:

> as we have static intializers in classes I thought I should add object
> initializers too. They are recognized by the grammar already, just not
> implemented. So I implemented the needed code and wrote a test
>
> class Foo {
>     def bar = 1
>     { bar = 2 }
> }
>
> def f = new Foo()
> assert f.bar==2
>
>
> now this doesn't work, because the grammar thinks, the code in brackets
> is part of a closure called on an Integer! It is ok, if I put an ";"
> after the 1
>
> class Foo {
>     def bar = 1;
>     { bar = 2 }
> }
>
> def f = new Foo()
> assert f.bar==2
>
>
> so what should we do? I am unsure if I am able to recognize this case
> somehow and give a more meaningfull error message. foridding calls to
> closures outside methods doesn't look like a good way to me too.
> Removing the initializer completly is another option, but then we should
> remove it from the grammar as well.
>
> comments?
>
> bye blackdrag
>

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Ray Cromwell]

BTW, in the Ruby example, the "traits" method creates class methods with
  read-only values, my groovy example creates read/write properties.



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 25 Jun 2006, at 21:19, Jochen Theodorou wrote:

>
> so what should we do? I am unsure if I am able to recognize this  
> case somehow and give a more meaningfull error message. foridding  
> calls to closures outside methods doesn't look like a good way to  
> me too. Removing the initializer completly is another option, but  
> then we should remove it from the grammar as well.


We have this problem in methods too, of course. Our solution there  
was to disallow stand alone blocks.

I don't see how you can recognise this as an error. We have discussed  
and rejected the solution of requiring that the "{" of the closure  
ids on the same line as the call.

If you wee to remove the initialiser from the grammar the example you  
quote would still compile successfully wouldn't it?

My view is that we keep the initialiser and require people to put the  
semicolon in.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

John Wilson schrieb:

>
> On 25 Jun 2006, at 21:19, Jochen Theodorou wrote:
>
>>
>> so what should we do? I am unsure if I am able to recognize this case
>> somehow and give a more meaningfull error message. foridding calls to
>> closures outside methods doesn't look like a good way to me too.
>> Removing the initializer completly is another option, but then we
>> should remove it from the grammar as well.
>
> We have this problem in methods too, of course. Our solution there was
> to disallow stand alone blocks.

ah right, I remember

> I don't see how you can recognise this as an error.

I too not ;)

> We have discussed
> and rejected the solution of requiring that the "{" of the closure ids
> on the same line as the call.

yes.

> If you wee to remove the initialiser from the grammar the example you
> quote would still compile successfully wouldn't it?

It would, yes.

> My view is that we keep the initialiser and require people to put the
> semicolon in.

This means, leave it as it is now? That's ok with me.


bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

---------------------------------------------------------------------
To unsubscribe from this list please visit:

    http://xircles.codehaus.org/manage_email