Methods available to closures

[Jeff Philp]

Hi,

Please can someone help me understand why Groovy allows

// Beginning
def closureA = { println 'closure A' }
def closureB = { println 'closure B' }
def closureC = { closureA(); closureB() }

closureC()
// End

to work, however if I rearrange the closures to be like

// Beginning
def closureC = { closureA(); closureB() }
def closureA = { println 'closure A' }
def closureB = { println 'closure B' }

closureC()
// End

a MissingMethodException is thrown.  I have read the scoping rules for
access external variables for closures, but
I can't quite see why this code fails.

Many thanks,
Jeffrey Philp

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

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

Closures are variables.  At the point when you say "closureA()", there is no such thing as
"closureA()" declared.

It'd be like saying:

def a = 1
def b = 2
def c = a + b

And then asking why it's bogus if you rearrange it to:

def c = a + b
def a = 1
def b = 2

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jeff Philp wrote:

> Hi,
>
> Please can someone help me understand why Groovy allows
>
> // Beginning
> def closureA = { println 'closure A' }
> def closureB = { println 'closure B' }
> def closureC = { closureA(); closureB() }
>
> closureC()
> // End
>
> to work, however if I rearrange the closures to be like
>
> // Beginning
> def closureC = { closureA(); closureB() }
> def closureA = { println 'closure A' }
> def closureB = { println 'closure B' }
>
> closureC()
> // End
>
> a MissingMethodException is thrown.  I have read the scoping rules for
> access external variables for closures, but
> I can't quite see why this code fails.
>
> Many thanks,
> Jeffrey Philp
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Also, in your example, closureA is of type Object, and you initialize it
to a closure, but you could later assign something else to it if you
wanted.  So e.g. you should be able to do:

def closureA = 23
def closureC = { closureA() }
closureA = { println 'closureA' }

closureC()

So in the line:

def closureC = { closureA() }

All the compiler knows is that there's a variable in scope called
closureA, but it doesn't know whether it holds a closure or something else.

So we can't have special case scoping for closures, since the compiler
doesn't know the type of your local variables.

Best,
Martin


Robert Fischer wrote:

> Closures are variables.  At the point when you say "closureA()", there
> is no such thing as "closureA()" declared.
>
> It'd be like saying:
>
> def a = 1
> def b = 2
> def c = a + b
>
> And then asking why it's bogus if you rearrange it to:
>
> def c = a + b
> def a = 1
> def b = 2
>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Jeff Philp wrote:
>> Hi,
>>
>> Please can someone help me understand why Groovy allows
>>
>> // Beginning
>> def closureA = { println 'closure A' }
>> def closureB = { println 'closure B' }
>> def closureC = { closureA(); closureB() }
>>
>> closureC()
>> // End
>>
>> to work, however if I rearrange the closures to be like
>>
>> // Beginning
>> def closureC = { closureA(); closureB() }
>> def closureA = { println 'closure A' }
>> def closureB = { println 'closure B' }
>>
>> closureC()
>> // End
>>
>> a MissingMethodException is thrown.  I have read the scoping rules for
>> access external variables for closures, but
>> I can't quite see why this code fails.
>>
>> Many thanks,
>> Jeffrey Philp
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

If your such usage of closures is in a script, you can use the workaround to not "def" the closure variables:

====================================
def closureC = { closureA(); closureB() }
closureA = { println 'closure A' }
closureB = { println 'closure B' }

closureC()
====================================

-- Roshan

On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin <martin@...> wrote:

Also, in your example, closureA is of type Object, and you initialize it to a closure, but you could later assign something else to it if you wanted.  So e.g. you should be able to do:

def closureA = 23
def closureC = { closureA() }
closureA = { println 'closureA' }

closureC()

So in the line:

def closureC = { closureA() }

All the compiler knows is that there's a variable in scope called closureA, but it doesn't know whether it holds a closure or something else.

So we can't have special case scoping for closures, since the compiler doesn't know the type of your local variables.

Best,
Martin

Robert Fischer wrote:

Closures are variables.  At the point when you say "closureA()", there is no such thing as "closureA()" declared.

It'd be like saying:

def a = 1
def b = 2
def c = a + b

And then asking why it's bogus if you rearrange it to:

def c = a + b
def a = 1
def b = 2

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jeff Philp wrote:

Hi,

Please can someone help me understand why Groovy allows

// Beginning
def closureA = { println 'closure A' }
def closureB = { println 'closure B' }
def closureC = { closureA(); closureB() }

closureC()
// End

to work, however if I rearrange the closures to be like

// Beginning
def closureC = { closureA(); closureB() }
def closureA = { println 'closure A' }
def closureB = { println 'closure B' }

closureC()
// End

a MissingMethodException is thrown.  I have read the scoping rules for
access external variables for closures, but
I can't quite see why this code fails.

Many thanks,
Jeffrey Philp

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

   http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

[Robert Fischer]

Oh, that's dirty.

To be clear, what's going on here is that the scripts autovivify properties.  So you're changing
"closureA" and "closureB" from variables to properties, and then the closure grabs the properties
later on.

So this is all a consequence of scripts and their funny property magic.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

> If your such usage of closures is in a script, you can use the
> workaround to not "def" the closure variables:
>
> ====================================
> def closureC = { closureA(); closureB() }
> closureA = { println 'closure A' }
> closureB = { println 'closure B' }
>
> closureC()
> ====================================
>
> -- Roshan
>
> On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
> <martin@... <mailto:martin@...>> wrote:
>
>     Also, in your example, closureA is of type Object, and you
>     initialize it to a closure, but you could later assign something
>     else to it if you wanted.  So e.g. you should be able to do:
>
>     def closureA = 23
>     def closureC = { closureA() }
>     closureA = { println 'closureA' }
>
>     closureC()
>
>     So in the line:
>
>     def closureC = { closureA() }
>
>     All the compiler knows is that there's a variable in scope called
>     closureA, but it doesn't know whether it holds a closure or
>     something else.
>
>     So we can't have special case scoping for closures, since the
>     compiler doesn't know the type of your local variables.
>
>     Best,
>     Martin
>
>
>
>     Robert Fischer wrote:
>
>         Closures are variables.  At the point when you say "closureA()",
>         there is no such thing as "closureA()" declared.
>
>         It'd be like saying:
>
>         def a = 1
>         def b = 2
>         def c = a + b
>
>         And then asking why it's bogus if you rearrange it to:
>
>         def c = a + b
>         def a = 1
>         def b = 2
>
>         ~~ Robert Fischer, Smokejumper IT Consulting.
>         Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>         Grails Expert Retainer Services
>         http://smokejumperit.com/grails-retainer/
>
>
>         Jeff Philp wrote:
>
>             Hi,
>
>             Please can someone help me understand why Groovy allows
>
>             // Beginning
>             def closureA = { println 'closure A' }
>             def closureB = { println 'closure B' }
>             def closureC = { closureA(); closureB() }
>
>             closureC()
>             // End
>
>             to work, however if I rearrange the closures to be like
>
>             // Beginning
>             def closureC = { closureA(); closureB() }
>             def closureA = { println 'closure A' }
>             def closureB = { println 'closure B' }
>
>             closureC()
>             // End
>
>             a MissingMethodException is thrown.  I have read the scoping
>             rules for
>             access external variables for closures, but
>             I can't quite see why this code fails.
>
>             Many thanks,
>             Jeffrey Philp
>
>             ---------------------------------------------------------------------
>             To unsubscribe from this list, please visit:
>
>                http://xircles.codehaus.org/manage_email
>
>
>
>
>         ---------------------------------------------------------------------
>         To unsubscribe from this list, please visit:
>
>           http://xircles.codehaus.org/manage_email
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

Sure?

And how does one define these properties in a script that the closures will grab? Can it be done without using binding? Can it be done in some way that these other vivified properties will be accessible only when closures themselves as declared as properties but not when they are declared as variables?

As far as I know the only way to define script-class level properties in a script is to add them to script's binding, and that is available to the closures any way - whether you define them as variables or define them as properties (without def)

See below:
1)
================closures defined as properties=============
a = 100
b = 200

def closureC = { closureA(); closureB() }
closureA = { println "closure A - $a" } // can access a
closureB = { println "closure B - $b" } // can access b

closureC()
=====================================================

2)
================closures defined as variables=============
a = 100
b = 200

def closureA = { println "closure A - $a" } // can still access a
def closureB = { println "closure B - $b" } // can still access b
def closureC = { closureA(); closureB() }

closureC()
=====================================================

-- Roshan

On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer <robert.fischer@...> wrote:

Oh, that's dirty.

To be clear, what's going on here is that the scripts autovivify properties.  So you're changing "closureA" and "closureB" from variables to properties, and then the closure grabs the properties later on.

So this is all a consequence of scripts and their funny property magic.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/

Roshan Dawrani wrote:

If your such usage of closures is in a script, you can use the workaround to not "def" the closure variables:

====================================
def closureC = { closureA(); closureB() }
closureA = { println 'closure A' }
closureB = { println 'closure B' }

closureC()
====================================

-- Roshan

On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin <martin@... <mailto:martin@...>> wrote:

   Also, in your example, closureA is of type Object, and you
   initialize it to a closure, but you could later assign something
   else to it if you wanted.  So e.g. you should be able to do:

   def closureA = 23
   def closureC = { closureA() }
   closureA = { println 'closureA' }

   closureC()

   So in the line:

   def closureC = { closureA() }

   All the compiler knows is that there's a variable in scope called
   closureA, but it doesn't know whether it holds a closure or
   something else.

   So we can't have special case scoping for closures, since the
   compiler doesn't know the type of your local variables.

   Best,
   Martin



   Robert Fischer wrote:

       Closures are variables.  At the point when you say "closureA()",
       there is no such thing as "closureA()" declared.

       It'd be like saying:

       def a = 1
       def b = 2
       def c = a + b

       And then asking why it's bogus if you rearrange it to:

       def c = a + b
       def a = 1
       def b = 2

       ~~ Robert Fischer, Smokejumper IT Consulting.
       Enfranchised Mind Blog http://EnfranchisedMind.com/blog

       Grails Expert Retainer Services
       http://smokejumperit.com/grails-retainer/


       Jeff Philp wrote:

           Hi,

           Please can someone help me understand why Groovy allows

           // Beginning
           def closureA = { println 'closure A' }
           def closureB = { println 'closure B' }
           def closureC = { closureA(); closureB() }

           closureC()
           // End

           to work, however if I rearrange the closures to be like

           // Beginning
           def closureC = { closureA(); closureB() }
           def closureA = { println 'closure A' }
           def closureB = { println 'closure B' }

           closureC()
           // End

           a MissingMethodException is thrown.  I have read the scoping
           rules for
           access external variables for closures, but
           I can't quite see why this code fails.

           Many thanks,
           Jeffrey Philp

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

              http://xircles.codehaus.org/manage_email




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

         http://xircles.codehaus.org/manage_email



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

     http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

[Robert Fischer]

Email communication just broke down on us.  Maybe I'm just tired, but I'm lost.

Are you disagreeing with something I said?  I'm a confused by whether the questions were rhetorical
or inquiring, and what to make of "Sure?".

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

> Sure?
>
> And how does one define these properties in a script that the closures
> will grab? Can it be done without using binding? Can it be done in some
> way that these other vivified properties will be accessible only when
> closures themselves as declared as properties but not when they are
> declared as variables?
>
> As far as I know the only way to define script-class level properties in
> a script is to add them to script's binding, and that is available to
> the closures any way - whether you define them as variables or define
> them as properties (without def)
>
> See below:
> 1)
> ================closures defined as properties=============
> a = 100
> b = 200
>
> def closureC = { closureA(); closureB() }
> closureA = { println "closure A - $a" } // can access a
> closureB = { println "closure B - $b" } // can access b
>
> closureC()
> =====================================================
>
> 2)
> ================closures defined as variables=============
> a = 100
> b = 200
>
> def closureA = { println "closure A - $a" } // can still access a
> def closureB = { println "closure B - $b" } // can still access b
> def closureC = { closureA(); closureB() }
>
> closureC()
> =====================================================
>
> -- Roshan
>
> On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer
> <robert.fischer@...
> <mailto:robert.fischer@...>> wrote:
>
>     Oh, that's dirty.
>
>     To be clear, what's going on here is that the scripts autovivify
>     properties.  So you're changing "closureA" and "closureB" from
>     variables to properties, and then the closure grabs the properties
>     later on.
>
>     So this is all a consequence of scripts and their funny property magic.
>
>
>     ~~ Robert Fischer, Smokejumper IT Consulting.
>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>     Grails Expert Retainer Services
>     http://smokejumperit.com/grails-retainer/
>
>
>     Roshan Dawrani wrote:
>
>         If your such usage of closures is in a script, you can use the
>         workaround to not "def" the closure variables:
>
>         ====================================
>         def closureC = { closureA(); closureB() }
>         closureA = { println 'closure A' }
>         closureB = { println 'closure B' }
>
>         closureC()
>         ====================================
>
>         -- Roshan
>
>         On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
>         <martin@... <mailto:martin@...>
>         <mailto:martin@...
>         <mailto:martin@...>>> wrote:
>
>            Also, in your example, closureA is of type Object, and you
>            initialize it to a closure, but you could later assign something
>            else to it if you wanted.  So e.g. you should be able to do:
>
>            def closureA = 23
>            def closureC = { closureA() }
>            closureA = { println 'closureA' }
>
>            closureC()
>
>            So in the line:
>
>            def closureC = { closureA() }
>
>            All the compiler knows is that there's a variable in scope called
>            closureA, but it doesn't know whether it holds a closure or
>            something else.
>
>            So we can't have special case scoping for closures, since the
>            compiler doesn't know the type of your local variables.
>
>            Best,
>            Martin
>
>
>
>            Robert Fischer wrote:
>
>                Closures are variables.  At the point when you say
>         "closureA()",
>                there is no such thing as "closureA()" declared.
>
>                It'd be like saying:
>
>                def a = 1
>                def b = 2
>                def c = a + b
>
>                And then asking why it's bogus if you rearrange it to:
>
>                def c = a + b
>                def a = 1
>                def b = 2
>
>                ~~ Robert Fischer, Smokejumper IT Consulting.
>                Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>                Grails Expert Retainer Services
>                http://smokejumperit.com/grails-retainer/
>
>
>                Jeff Philp wrote:
>
>                    Hi,
>
>                    Please can someone help me understand why Groovy allows
>
>                    // Beginning
>                    def closureA = { println 'closure A' }
>                    def closureB = { println 'closure B' }
>                    def closureC = { closureA(); closureB() }
>
>                    closureC()
>                    // End
>
>                    to work, however if I rearrange the closures to be like
>
>                    // Beginning
>                    def closureC = { closureA(); closureB() }
>                    def closureA = { println 'closure A' }
>                    def closureB = { println 'closure B' }
>
>                    closureC()
>                    // End
>
>                    a MissingMethodException is thrown.  I have read the
>         scoping
>                    rules for
>                    access external variables for closures, but
>                    I can't quite see why this code fails.
>
>                    Many thanks,
>                    Jeffrey Philp
>
>                  
>          ---------------------------------------------------------------------
>                    To unsubscribe from this list, please visit:
>
>                       http://xircles.codehaus.org/manage_email
>
>
>
>
>              
>          ---------------------------------------------------------------------
>                To unsubscribe from this list, please visit:
>
>                  http://xircles.codehaus.org/manage_email
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe from this list, please visit:
>
>              http://xircles.codehaus.org/manage_email
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

I am not sure how else to ask the questions. That's why I gave 2 code examples too. ("Sure?" meant to ask "Are you sure the solution is dirty or that's just too fast an objection?")

Let me try one more example:

Even to the closures that are defined as variables, the properties of the owner class are accessible any way, right? (because property access, method access get routed through the owner instance?)

=========================
def closureA = { println "closure A - $a" }

closureA()

def getA() {
    "propA"
}
=========================

So what downsides do you see in defining the closures as binding variables? What difference in their behavior do you see?

-- Roshan

On Mon, Nov 2, 2009 at 9:02 AM, Robert Fischer <robert.fischer@...> wrote:

Email communication just broke down on us.  Maybe I'm just tired, but I'm lost.

Are you disagreeing with something I said?  I'm a confused by whether the questions were rhetorical or inquiring, and what to make of "Sure?".

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

Sure?

And how does one define these properties in a script that the closures will grab? Can it be done without using binding? Can it be done in some way that these other vivified properties will be accessible only when closures themselves as declared as properties but not when they are declared as variables?

As far as I know the only way to define script-class level properties in a script is to add them to script's binding, and that is available to the closures any way - whether you define them as variables or define them as properties (without def)

See below:
1)
================closures defined as properties=============
a = 100
b = 200

def closureC = { closureA(); closureB() }
closureA = { println "closure A - $a" } // can access a
closureB = { println "closure B - $b" } // can access b

closureC()
=====================================================

2)
================closures defined as variables=============
a = 100
b = 200

def closureA = { println "closure A - $a" } // can still access a
def closureB = { println "closure B - $b" } // can still access b
def closureC = { closureA(); closureB() }

closureC()
=====================================================

-- Roshan

On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer <robert.fischer@... <mailto:robert.fischer@...>> wrote:

   Oh, that's dirty.

   To be clear, what's going on here is that the scripts autovivify
   properties.  So you're changing "closureA" and "closureB" from
   variables to properties, and then the closure grabs the properties
   later on.

   So this is all a consequence of scripts and their funny property magic.


   ~~ Robert Fischer, Smokejumper IT Consulting.
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Grails Expert Retainer Services
   http://smokejumperit.com/grails-retainer/


   Roshan Dawrani wrote:

       If your such usage of closures is in a script, you can use the
       workaround to not "def" the closure variables:

       ====================================
       def closureC = { closureA(); closureB() }
       closureA = { println 'closure A' }
       closureB = { println 'closure B' }

       closureC()
       ====================================

       -- Roshan

       On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
       <martin@... <mailto:martin@...>

       <mailto:martin@...

       <mailto:martin@...>>> wrote:

          Also, in your example, closureA is of type Object, and you
          initialize it to a closure, but you could later assign something
          else to it if you wanted.  So e.g. you should be able to do:

          def closureA = 23
          def closureC = { closureA() }
          closureA = { println 'closureA' }

          closureC()

          So in the line:

          def closureC = { closureA() }

          All the compiler knows is that there's a variable in scope called
          closureA, but it doesn't know whether it holds a closure or
          something else.

          So we can't have special case scoping for closures, since the
          compiler doesn't know the type of your local variables.

          Best,
          Martin



          Robert Fischer wrote:

              Closures are variables.  At the point when you say
       "closureA()",
              there is no such thing as "closureA()" declared.

              It'd be like saying:

              def a = 1
              def b = 2
              def c = a + b

              And then asking why it's bogus if you rearrange it to:

              def c = a + b
              def a = 1
              def b = 2

              ~~ Robert Fischer, Smokejumper IT Consulting.
              Enfranchised Mind Blog http://EnfranchisedMind.com/blog

              Grails Expert Retainer Services
              http://smokejumperit.com/grails-retainer/


              Jeff Philp wrote:

                  Hi,

                  Please can someone help me understand why Groovy allows

                  // Beginning
                  def closureA = { println 'closure A' }
                  def closureB = { println 'closure B' }
                  def closureC = { closureA(); closureB() }

                  closureC()
                  // End

                  to work, however if I rearrange the closures to be like

                  // Beginning
                  def closureC = { closureA(); closureB() }
                  def closureA = { println 'closure A' }
                  def closureB = { println 'closure B' }

                  closureC()
                  // End

                  a MissingMethodException is thrown.  I have read the
       scoping
                  rules for
                  access external variables for closures, but
                  I can't quite see why this code fails.

                  Many thanks,
                  Jeffrey Philp

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

                     http://xircles.codehaus.org/manage_email




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

                http://xircles.codehaus.org/manage_email



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

            http://xircles.codehaus.org/manage_email




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

     http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

[Robert Fischer]

By playing fast and loose with properties, scripts basically allow you to code a version of Groovy
where you don't have to declare variables.  Which I consider a kind of dirty stunt, particularly
since the original question demonstrated some confusion about closures vs. methods to begin with.
Now throwing properties vs. variables into the mix, and particularly properties vs. variables in the
context of scripts (as opposed to anywhere else in the langauge) is just muddying the watter.
That's what I was down on.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

> I am not sure how else to ask the questions. That's why I gave 2 code
> examples too. ("Sure?" meant to ask "Are you sure the solution is dirty
> or that's just too fast an objection?")
>
> Let me try one more example:
>
> Even to the closures that are defined as variables, the properties of
> the owner class are accessible any way, right? (because property access,
> method access get routed through the owner instance?)
>
> =========================
> def closureA = { println "closure A - $a" }
>
> closureA()
>
> def getA() {
>     "propA"
> }
> =========================
>
> So what downsides do you see in defining the closures as binding
> variables? What difference in their behavior do you see?
>
> -- Roshan
>
>
> On Mon, Nov 2, 2009 at 9:02 AM, Robert Fischer
> <robert.fischer@...
> <mailto:robert.fischer@...>> wrote:
>
>     Email communication just broke down on us.  Maybe I'm just tired,
>     but I'm lost.
>
>     Are you disagreeing with something I said?  I'm a confused by
>     whether the questions were rhetorical or inquiring, and what to make
>     of "Sure?".
>
>
>     ~~ Robert Fischer, Smokejumper IT Consulting.
>     Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>     Grails Expert Retainer Services
>     http://smokejumperit.com/grails-retainer/
>
>
>     Roshan Dawrani wrote:
>
>         Sure?
>
>         And how does one define these properties in a script that the
>         closures will grab? Can it be done without using binding? Can it
>         be done in some way that these other vivified properties will be
>         accessible only when closures themselves as declared as
>         properties but not when they are declared as variables?
>
>         As far as I know the only way to define script-class level
>         properties in a script is to add them to script's binding, and
>         that is available to the closures any way - whether you define
>         them as variables or define them as properties (without def)
>
>         See below:
>         1)
>         ================closures defined as properties=============
>         a = 100
>         b = 200
>
>         def closureC = { closureA(); closureB() }
>         closureA = { println "closure A - $a" } // can access a
>         closureB = { println "closure B - $b" } // can access b
>
>         closureC()
>         =====================================================
>
>         2)
>         ================closures defined as variables=============
>         a = 100
>         b = 200
>
>         def closureA = { println "closure A - $a" } // can still access a
>         def closureB = { println "closure B - $b" } // can still access b
>         def closureC = { closureA(); closureB() }
>
>         closureC()
>         =====================================================
>
>         -- Roshan
>
>         On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer
>         <robert.fischer@...
>         <mailto:robert.fischer@...>
>         <mailto:robert.fischer@...
>         <mailto:robert.fischer@...>>> wrote:
>
>            Oh, that's dirty.
>
>            To be clear, what's going on here is that the scripts autovivify
>            properties.  So you're changing "closureA" and "closureB" from
>            variables to properties, and then the closure grabs the
>         properties
>            later on.
>
>            So this is all a consequence of scripts and their funny
>         property magic.
>
>
>            ~~ Robert Fischer, Smokejumper IT Consulting.
>            Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
>            Grails Expert Retainer Services
>            http://smokejumperit.com/grails-retainer/
>
>
>            Roshan Dawrani wrote:
>
>                If your such usage of closures is in a script, you can
>         use the
>                workaround to not "def" the closure variables:
>
>                ====================================
>                def closureC = { closureA(); closureB() }
>                closureA = { println 'closure A' }
>                closureB = { println 'closure B' }
>
>                closureC()
>                ====================================
>
>                -- Roshan
>
>                On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
>                <martin@...
>         <mailto:martin@...>
>         <mailto:martin@... <mailto:martin@...>>
>                <mailto:martin@...
>         <mailto:martin@...>
>
>                <mailto:martin@...
>         <mailto:martin@...>>>> wrote:
>
>                   Also, in your example, closureA is of type Object, and you
>                   initialize it to a closure, but you could later assign
>         something
>                   else to it if you wanted.  So e.g. you should be able
>         to do:
>
>                   def closureA = 23
>                   def closureC = { closureA() }
>                   closureA = { println 'closureA' }
>
>                   closureC()
>
>                   So in the line:
>
>                   def closureC = { closureA() }
>
>                   All the compiler knows is that there's a variable in
>         scope called
>                   closureA, but it doesn't know whether it holds a
>         closure or
>                   something else.
>
>                   So we can't have special case scoping for closures,
>         since the
>                   compiler doesn't know the type of your local variables.
>
>                   Best,
>                   Martin
>
>
>
>                   Robert Fischer wrote:
>
>                       Closures are variables.  At the point when you say
>                "closureA()",
>                       there is no such thing as "closureA()" declared.
>
>                       It'd be like saying:
>
>                       def a = 1
>                       def b = 2
>                       def c = a + b
>
>                       And then asking why it's bogus if you rearrange it to:
>
>                       def c = a + b
>                       def a = 1
>                       def b = 2
>
>                       ~~ Robert Fischer, Smokejumper IT Consulting.
>                       Enfranchised Mind Blog
>         http://EnfranchisedMind.com/blog
>
>                       Grails Expert Retainer Services
>                       http://smokejumperit.com/grails-retainer/
>
>
>                       Jeff Philp wrote:
>
>                           Hi,
>
>                           Please can someone help me understand why
>         Groovy allows
>
>                           // Beginning
>                           def closureA = { println 'closure A' }
>                           def closureB = { println 'closure B' }
>                           def closureC = { closureA(); closureB() }
>
>                           closureC()
>                           // End
>
>                           to work, however if I rearrange the closures
>         to be like
>
>                           // Beginning
>                           def closureC = { closureA(); closureB() }
>                           def closureA = { println 'closure A' }
>                           def closureB = { println 'closure B' }
>
>                           closureC()
>                           // End
>
>                           a MissingMethodException is thrown.  I have
>         read the
>                scoping
>                           rules for
>                           access external variables for closures, but
>                           I can't quite see why this code fails.
>
>                           Many thanks,
>                           Jeffrey Philp
>
>                                
>         ---------------------------------------------------------------------
>                           To unsubscribe from this list, please visit:
>
>                              http://xircles.codehaus.org/manage_email
>
>
>
>
>                            
>         ---------------------------------------------------------------------
>                       To unsubscribe from this list, please visit:
>
>                         http://xircles.codehaus.org/manage_email
>
>
>
>                        
>         ---------------------------------------------------------------------
>                   To unsubscribe from this list, please visit:
>
>                     http://xircles.codehaus.org/manage_email
>
>
>
>
>          
>          ---------------------------------------------------------------------
>            To unsubscribe from this list, please visit:
>
>              http://xircles.codehaus.org/manage_email
>
>
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe from this list, please visit:
>
>       http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

Well, if you have an example for any difference in behavior of closures (defined as variables vs defined as properties), please show it, else let's leave it.

What you consider a dirty stunt, I may not consider - that's subjective stuff.

On Mon, Nov 2, 2009 at 9:19 AM, Robert Fischer <robert.fischer@...> wrote:

By playing fast and loose with properties, scripts basically allow you to code a version of Groovy where you don't have to declare variables.  Which I consider a kind of dirty stunt, particularly since the original question demonstrated some confusion about closures vs. methods to begin with. Now throwing properties vs. variables into the mix, and particularly properties vs. variables in the context of scripts (as opposed to anywhere else in the langauge) is just muddying the watter. That's what I was down on.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

I am not sure how else to ask the questions. That's why I gave 2 code examples too. ("Sure?" meant to ask "Are you sure the solution is dirty or that's just too fast an objection?")

Let me try one more example:

Even to the closures that are defined as variables, the properties of the owner class are accessible any way, right? (because property access, method access get routed through the owner instance?)

=========================
def closureA = { println "closure A - $a" }

closureA()

def getA() {
   "propA"
}
=========================

So what downsides do you see in defining the closures as binding variables? What difference in their behavior do you see?

-- Roshan

On Mon, Nov 2, 2009 at 9:02 AM, Robert Fischer <robert.fischer@... <mailto:robert.fischer@...>> wrote:

   Email communication just broke down on us.  Maybe I'm just tired,
   but I'm lost.

   Are you disagreeing with something I said?  I'm a confused by
   whether the questions were rhetorical or inquiring, and what to make
   of "Sure?".


   ~~ Robert Fischer, Smokejumper IT Consulting.
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Grails Expert Retainer Services
   http://smokejumperit.com/grails-retainer/


   Roshan Dawrani wrote:

       Sure?

       And how does one define these properties in a script that the
       closures will grab? Can it be done without using binding? Can it
       be done in some way that these other vivified properties will be
       accessible only when closures themselves as declared as
       properties but not when they are declared as variables?

       As far as I know the only way to define script-class level
       properties in a script is to add them to script's binding, and
       that is available to the closures any way - whether you define
       them as variables or define them as properties (without def)

       See below:
       1)
       ================closures defined as properties=============
       a = 100
       b = 200

       def closureC = { closureA(); closureB() }
       closureA = { println "closure A - $a" } // can access a
       closureB = { println "closure B - $b" } // can access b

       closureC()
       =====================================================

       2)
       ================closures defined as variables=============
       a = 100
       b = 200

       def closureA = { println "closure A - $a" } // can still access a
       def closureB = { println "closure B - $b" } // can still access b
       def closureC = { closureA(); closureB() }

       closureC()
       =====================================================

       -- Roshan

       On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer
       <robert.fischer@...
       <mailto:robert.fischer@...>
       <mailto:robert.fischer@...
       <mailto:robert.fischer@...>>> wrote:

          Oh, that's dirty.

          To be clear, what's going on here is that the scripts autovivify
          properties.  So you're changing "closureA" and "closureB" from
          variables to properties, and then the closure grabs the
       properties
          later on.

          So this is all a consequence of scripts and their funny
       property magic.


          ~~ Robert Fischer, Smokejumper IT Consulting.
          Enfranchised Mind Blog http://EnfranchisedMind.com/blog

          Grails Expert Retainer Services
          http://smokejumperit.com/grails-retainer/


          Roshan Dawrani wrote:

              If your such usage of closures is in a script, you can
       use the
              workaround to not "def" the closure variables:

              ====================================
              def closureC = { closureA(); closureB() }
              closureA = { println 'closure A' }
              closureB = { println 'closure B' }

              closureC()
              ====================================

              -- Roshan

              On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
              <martin@...
       <mailto:martin@...>
       <mailto:martin@... <mailto:martin@...>>
              <mailto:martin@...
       <mailto:martin@...>

              <mailto:martin@...
       <mailto:martin@...>>>> wrote:

                 Also, in your example, closureA is of type Object, and you
                 initialize it to a closure, but you could later assign
       something
                 else to it if you wanted.  So e.g. you should be able
       to do:

                 def closureA = 23
                 def closureC = { closureA() }
                 closureA = { println 'closureA' }

                 closureC()

                 So in the line:

                 def closureC = { closureA() }

                 All the compiler knows is that there's a variable in
       scope called
                 closureA, but it doesn't know whether it holds a
       closure or
                 something else.

                 So we can't have special case scoping for closures,
       since the
                 compiler doesn't know the type of your local variables.

                 Best,
                 Martin



                 Robert Fischer wrote:

                     Closures are variables.  At the point when you say
              "closureA()",
                     there is no such thing as "closureA()" declared.

                     It'd be like saying:

                     def a = 1
                     def b = 2
                     def c = a + b

                     And then asking why it's bogus if you rearrange it to:

                     def c = a + b
                     def a = 1
                     def b = 2

                     ~~ Robert Fischer, Smokejumper IT Consulting.
                     Enfranchised Mind Blog
       http://EnfranchisedMind.com/blog

                     Grails Expert Retainer Services
                     http://smokejumperit.com/grails-retainer/


                     Jeff Philp wrote:

                         Hi,

                         Please can someone help me understand why
       Groovy allows

                         // Beginning
                         def closureA = { println 'closure A' }
                         def closureB = { println 'closure B' }
                         def closureC = { closureA(); closureB() }

                         closureC()
                         // End

                         to work, however if I rearrange the closures
       to be like

                         // Beginning
                         def closureC = { closureA(); closureB() }
                         def closureA = { println 'closure A' }
                         def closureB = { println 'closure B' }

                         closureC()
                         // End

                         a MissingMethodException is thrown.  I have
       read the
              scoping
                         rules for
                         access external variables for closures, but
                         I can't quite see why this code fails.

                         Many thanks,
                         Jeffrey Philp

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

                            http://xircles.codehaus.org/manage_email




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

                       http://xircles.codehaus.org/manage_email



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

                   http://xircles.codehaus.org/manage_email




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

            http://xircles.codehaus.org/manage_email




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

     http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

[Roshan Dawrani-2]

And the original question wasn't seeking any best practices on groovy coding - it was about a confusion in scoping rules of variables, and to me, the situation in the original question was that the user expected closureA, closureB, and closureC as script level fields, not as local variables and hence ran into this scoping related confusion. (Want to give it another read? :-) )
 
-- Roshan

On Mon, Nov 2, 2009 at 9:24 AM, Roshan Dawrani <roshandawrani@...> wrote:

Well, if you have an example for any difference in behavior of closures (defined as variables vs defined as properties), please show it, else let's leave it.

What you consider a dirty stunt, I may not consider - that's subjective stuff.

On Mon, Nov 2, 2009 at 9:19 AM, Robert Fischer <robert.fischer@...> wrote:

By playing fast and loose with properties, scripts basically allow you to code a version of Groovy where you don't have to declare variables.  Which I consider a kind of dirty stunt, particularly since the original question demonstrated some confusion about closures vs. methods to begin with. Now throwing properties vs. variables into the mix, and particularly properties vs. variables in the context of scripts (as opposed to anywhere else in the langauge) is just muddying the watter. That's what I was down on.

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Roshan Dawrani wrote:

I am not sure how else to ask the questions. That's why I gave 2 code examples too. ("Sure?" meant to ask "Are you sure the solution is dirty or that's just too fast an objection?")

Let me try one more example:

Even to the closures that are defined as variables, the properties of the owner class are accessible any way, right? (because property access, method access get routed through the owner instance?)

=========================
def closureA = { println "closure A - $a" }

closureA()

def getA() {
   "propA"
}
=========================

So what downsides do you see in defining the closures as binding variables? What difference in their behavior do you see?

-- Roshan

On Mon, Nov 2, 2009 at 9:02 AM, Robert Fischer <robert.fischer@... <mailto:robert.fischer@...>> wrote:

   Email communication just broke down on us.  Maybe I'm just tired,
   but I'm lost.

   Are you disagreeing with something I said?  I'm a confused by
   whether the questions were rhetorical or inquiring, and what to make
   of "Sure?".


   ~~ Robert Fischer, Smokejumper IT Consulting.
   Enfranchised Mind Blog http://EnfranchisedMind.com/blog

   Grails Expert Retainer Services
   http://smokejumperit.com/grails-retainer/


   Roshan Dawrani wrote:

       Sure?

       And how does one define these properties in a script that the
       closures will grab? Can it be done without using binding? Can it
       be done in some way that these other vivified properties will be
       accessible only when closures themselves as declared as
       properties but not when they are declared as variables?

       As far as I know the only way to define script-class level
       properties in a script is to add them to script's binding, and
       that is available to the closures any way - whether you define
       them as variables or define them as properties (without def)

       See below:
       1)
       ================closures defined as properties=============
       a = 100
       b = 200

       def closureC = { closureA(); closureB() }
       closureA = { println "closure A - $a" } // can access a
       closureB = { println "closure B - $b" } // can access b

       closureC()
       =====================================================

       2)
       ================closures defined as variables=============
       a = 100
       b = 200

       def closureA = { println "closure A - $a" } // can still access a
       def closureB = { println "closure B - $b" } // can still access b
       def closureC = { closureA(); closureB() }

       closureC()
       =====================================================

       -- Roshan

       On Mon, Nov 2, 2009 at 8:32 AM, Robert Fischer
       <robert.fischer@...
       <mailto:robert.fischer@...>
       <mailto:robert.fischer@...
       <mailto:robert.fischer@...>>> wrote:

          Oh, that's dirty.

          To be clear, what's going on here is that the scripts autovivify
          properties.  So you're changing "closureA" and "closureB" from
          variables to properties, and then the closure grabs the
       properties
          later on.

          So this is all a consequence of scripts and their funny
       property magic.


          ~~ Robert Fischer, Smokejumper IT Consulting.
          Enfranchised Mind Blog http://EnfranchisedMind.com/blog

          Grails Expert Retainer Services
          http://smokejumperit.com/grails-retainer/


          Roshan Dawrani wrote:

              If your such usage of closures is in a script, you can
       use the
              workaround to not "def" the closure variables:

              ====================================
              def closureC = { closureA(); closureB() }
              closureA = { println 'closure A' }
              closureB = { println 'closure B' }

              closureC()
              ====================================

              -- Roshan

              On Mon, Nov 2, 2009 at 4:27 AM, Martin C. Martin
              <martin@...
       <mailto:martin@...>
       <mailto:martin@... <mailto:martin@...>>
              <mailto:martin@...
       <mailto:martin@...>

              <mailto:martin@...
       <mailto:martin@...>>>> wrote:

                 Also, in your example, closureA is of type Object, and you
                 initialize it to a closure, but you could later assign
       something
                 else to it if you wanted.  So e.g. you should be able
       to do:

                 def closureA = 23
                 def closureC = { closureA() }
                 closureA = { println 'closureA' }

                 closureC()

                 So in the line:

                 def closureC = { closureA() }

                 All the compiler knows is that there's a variable in
       scope called
                 closureA, but it doesn't know whether it holds a
       closure or
                 something else.

                 So we can't have special case scoping for closures,
       since the
                 compiler doesn't know the type of your local variables.

                 Best,
                 Martin



                 Robert Fischer wrote:

                     Closures are variables.  At the point when you say
              "closureA()",
                     there is no such thing as "closureA()" declared.

                     It'd be like saying:

                     def a = 1
                     def b = 2
                     def c = a + b

                     And then asking why it's bogus if you rearrange it to:

                     def c = a + b
                     def a = 1
                     def b = 2

                     ~~ Robert Fischer, Smokejumper IT Consulting.
                     Enfranchised Mind Blog
       http://EnfranchisedMind.com/blog

                     Grails Expert Retainer Services
                     http://smokejumperit.com/grails-retainer/


                     Jeff Philp wrote:

                         Hi,

                         Please can someone help me understand why
       Groovy allows

                         // Beginning
                         def closureA = { println 'closure A' }
                         def closureB = { println 'closure B' }
                         def closureC = { closureA(); closureB() }

                         closureC()
                         // End

                         to work, however if I rearrange the closures
       to be like

                         // Beginning
                         def closureC = { closureA(); closureB() }
                         def closureA = { println 'closure A' }
                         def closureB = { println 'closure B' }

                         closureC()
                         // End

                         a MissingMethodException is thrown.  I have
       read the
              scoping
                         rules for
                         access external variables for closures, but
                         I can't quite see why this code fails.

                         Many thanks,
                         Jeffrey Philp

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

                            http://xircles.codehaus.org/manage_email




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

                       http://xircles.codehaus.org/manage_email



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

                   http://xircles.codehaus.org/manage_email




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

            http://xircles.codehaus.org/manage_email




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

     http://xircles.codehaus.org/manage_email

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

  http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Sun, 2009-11-01 at 22:02 -0500, Robert Fischer wrote:
> Oh, that's dirty.
>
> To be clear, what's going on here is that the scripts autovivify properties.  So you're changing
> "closureA" and "closureB" from variables to properties, and then the closure grabs the properties
> later on.
>
> So this is all a consequence of scripts and their funny property magic.

I am not sure all this talk of variable and properties works for me as a
model.  I find it much easier to thing of un"def"ed variables as
variables held in the global shared memory that is the binding
associated with the script.  I know it is un-cool to have global shared
memory -- and indeed global shared memory is anathema to parallelism --
but that is what the script binding of Groovy is, global shared memory.

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Guillaume Laforge-2]

On Mon, Nov 2, 2009 at 08:25, Russel Winder
<russel.winder@...> wrote:

> On Sun, 2009-11-01 at 22:02 -0500, Robert Fischer wrote:
>> Oh, that's dirty.
>>
>> To be clear, what's going on here is that the scripts autovivify properties.  So you're changing
>> "closureA" and "closureB" from variables to properties, and then the closure grabs the properties
>> later on.
>>
>> So this is all a consequence of scripts and their funny property magic.
>
> I am not sure all this talk of variable and properties works for me as a
> model.  I find it much easier to thing of un"def"ed variables as
> variables held in the global shared memory that is the binding
> associated with the script.  I know it is un-cool to have global shared
> memory -- and indeed global shared memory is anathema to parallelism --
> but that is what the script binding of Groovy is, global shared memory.

Furthermore, the binding is a great way of passing data outside the
script, when integrating Groovy in an application.

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Russel Winder wrote:
> On Sun, 2009-11-01 at 22:02 -0500, Robert Fischer wrote:
>
> I am not sure all this talk of variable and properties works for me as a
> model.  I find it much easier to thing of un"def"ed variables as
> variables held in the global shared memory that is the binding
> associated with the script.  I know it is un-cool to have global shared
> memory -- and indeed global shared memory is anathema to parallelism --
> but that is what the script binding of Groovy is, global shared memory.

Perhaps its better to think of it as specific to the Script object?  A
property statement like foo = 23 is equivalent to
this.setProperty("foo", 23).  When other classes want to access it, they
need to do myscript.foo, so "foo" isn't really global, at least in my
thinking.  So to me, its not un-cool or anathema to parallelism.  It's
basically just a Map, and I don't see people saying these things about Maps.

Best,
Martin

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Roshan Dawrani schrieb:
> Sure?
>
> And how does one define these properties in a script that the closures
> will grab? Can it be done without using binding? Can it be done in some
> way that these other vivified properties will be accessible only when
> closures themselves as declared as properties but not when they are
> declared as variables?

I think there is a bit confusion here... In a script you cannot really
define/declare properties or fields, only variables. You can assign
values to what I call dynamic properties. This assignment will kind of
define them, because the Binding logic will throw an exception if the
value has not been assigned before. But if you use a different Binding,
one that will never throw the exception, then there is no define/declare.

On the question on how closureC can access closureA and closureB before
the Closure part is defined:

def closureA,closureB
def closureC = { closureA(); closureB() }
closureA = { println 'closure A' }
closureB = { println 'closure B' }

closureC()

here closureX is always a local variable, still closureC can access
them. I should maybe here explain the difference... let us use a java
example:

class Foo {
   Object bar=1;
   void access() {
     System.out.println(bar);
     Object bar=2;
     System.out.println(bar);
   }
}

This will print first 1, then 2. That is because thee first bar refers
the field and the second one refers the local variable. The field is
then shadowed by the local variable. In Groovy:

def x = 1

will shadow any potential existing field/property of the name x. Thus if
I have

x=1
println x
def x = 2
println x

It would first print 1, then print 2. But the first x is from the
binding, the second from the local variable. That also means that x is
from the local variable only after x has been declared. After that it is
no longer possible to access the property from that scope using just x.

bye blackdrag

--
Jochen "blackdrag" Theodorou
The Groovy Project Tech Lead (http://groovy.codehaus.org)
http://blackdragsview.blogspot.com/


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

    http://xircles.codehaus.org/manage_email

[Jeff Philp]

Hi,

Thank you all for your answers.

Yes you are right, I was asking about scoping rules primarily, but it
was interesting to see the other points raised.

What confused me about the scoping rules, was that I understood
closures to be compiled segments of code which didn't check the names
of variables until the time that they were run.  And that they were
run in the environment that called it.

So if you refer to my first example

// Beginning
def closureC = { closureA(); closureB() }
def closureA = { println 'closure A' }
def closureB = { println 'closure B' }

closureC()
// End

I thought that when closureC was run at the end of the script, that it
would be able to see the same variables that would be accessible from
the implicit main block of this script.

I primarily work with the variables in the binding in scripts that
support a Java application, but I have seen the term "property" used
to refer to these variables.  I hope this is not a silly question, but
could I please seek clarification on the difference between "Property"
and "Variable" of a class.

Many Thanks,
Jeffrey Philp

2009/11/3 Jochen Theodorou <blackdrag@...>:

> Roshan Dawrani schrieb:
>>
>> Sure?
>>
>> And how does one define these properties in a script that the closures
>> will grab? Can it be done without using binding? Can it be done in some way
>> that these other vivified properties will be accessible only when closures
>> themselves as declared as properties but not when they are declared as
>> variables?
>
> I think there is a bit confusion here... In a script you cannot really
> define/declare properties or fields, only variables. You can assign values
> to what I call dynamic properties. This assignment will kind of define them,
> because the Binding logic will throw an exception if the value has not been
> assigned before. But if you use a different Binding, one that will never
> throw the exception, then there is no define/declare.
>
> On the question on how closureC can access closureA and closureB before the
> Closure part is defined:
>
> def closureA,closureB
> def closureC = { closureA(); closureB() }
> closureA = { println 'closure A' }
> closureB = { println 'closure B' }
>
> closureC()
>
> here closureX is always a local variable, still closureC can access them. I
> should maybe here explain the difference... let us use a java example:
>
> class Foo {
>  Object bar=1;
>  void access() {
>    System.out.println(bar);
>    Object bar=2;
>    System.out.println(bar);
>  }
> }
>
> This will print first 1, then 2. That is because thee first bar refers the
> field and the second one refers the local variable. The field is then
> shadowed by the local variable. In Groovy:
>
> def x = 1
>
> will shadow any potential existing field/property of the name x. Thus if I
> have
>
> x=1
> println x
> def x = 2
> println x
>
> It would first print 1, then print 2. But the first x is from the binding,
> the second from the local variable. That also means that x is from the local
> variable only after x has been declared. After that it is no longer possible
> to access the property from that scope using just x.
>
> bye blackdrag
>
> --
> Jochen "blackdrag" Theodorou
> The Groovy Project Tech Lead (http://groovy.codehaus.org)
> http://blackdragsview.blogspot.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Robert Fischer]

No: closures refer to variables at the scope where they are defined, not where they are called.
This is how closures close over variables.

If closures referred to variables at a scope where they were called, this code wouldn't work:

def makeClosure() {
   def printMe = "Hello, World"
   return { -> println printMe }
}

def toDo = makeClosure()
toDo()

But the fact that "printMe" is meaningful when toDo is called is the very essence of closures.

The description of scoping on Wikipedia is reasonable:
http://en.wikipedia.org/wiki/Lexical_scoping

~~ Robert Fischer, Smokejumper IT Consulting.
Enfranchised Mind Blog http://EnfranchisedMind.com/blog

Grails Expert Retainer Services
http://smokejumperit.com/grails-retainer/


Jeff Philp wrote:

> Hi,
>
> Thank you all for your answers.
>
> Yes you are right, I was asking about scoping rules primarily, but it
> was interesting to see the other points raised.
>
> What confused me about the scoping rules, was that I understood
> closures to be compiled segments of code which didn't check the names
> of variables until the time that they were run.  And that they were
> run in the environment that called it.
>
> So if you refer to my first example
>
> // Beginning
> def closureC = { closureA(); closureB() }
> def closureA = { println 'closure A' }
> def closureB = { println 'closure B' }
>
> closureC()
> // End
>
> I thought that when closureC was run at the end of the script, that it
> would be able to see the same variables that would be accessible from
> the implicit main block of this script.
>
> I primarily work with the variables in the binding in scripts that
> support a Java application, but I have seen the term "property" used
> to refer to these variables.  I hope this is not a silly question, but
> could I please seek clarification on the difference between "Property"
> and "Variable" of a class.
>
> Many Thanks,
> Jeffrey Philp
>
> 2009/11/3 Jochen Theodorou <blackdrag@...>:
>> Roshan Dawrani schrieb:
>>> Sure?
>>>
>>> And how does one define these properties in a script that the closures
>>> will grab? Can it be done without using binding? Can it be done in some way
>>> that these other vivified properties will be accessible only when closures
>>> themselves as declared as properties but not when they are declared as
>>> variables?
>> I think there is a bit confusion here... In a script you cannot really
>> define/declare properties or fields, only variables. You can assign values
>> to what I call dynamic properties. This assignment will kind of define them,
>> because the Binding logic will throw an exception if the value has not been
>> assigned before. But if you use a different Binding, one that will never
>> throw the exception, then there is no define/declare.
>>
>> On the question on how closureC can access closureA and closureB before the
>> Closure part is defined:
>>
>> def closureA,closureB
>> def closureC = { closureA(); closureB() }
>> closureA = { println 'closure A' }
>> closureB = { println 'closure B' }
>>
>> closureC()
>>
>> here closureX is always a local variable, still closureC can access them. I
>> should maybe here explain the difference... let us use a java example:
>>
>> class Foo {
>>  Object bar=1;
>>  void access() {
>>    System.out.println(bar);
>>    Object bar=2;
>>    System.out.println(bar);
>>  }
>> }
>>
>> This will print first 1, then 2. That is because thee first bar refers the
>> field and the second one refers the local variable. The field is then
>> shadowed by the local variable. In Groovy:
>>
>> def x = 1
>>
>> will shadow any potential existing field/property of the name x. Thus if I
>> have
>>
>> x=1
>> println x
>> def x = 2
>> println x
>>
>> It would first print 1, then print 2. But the first x is from the binding,
>> the second from the local variable. That also means that x is from the local
>> variable only after x has been declared. After that it is no longer possible
>> to access the property from that scope using just x.
>>
>> bye blackdrag
>>
>> --
>> Jochen "blackdrag" Theodorou
>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>> http://blackdragsview.blogspot.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>   http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>     http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

What Robert said is true and explains what you're seeing when you use
"def", which declares a local variable.

However, if the variable isn't found at compile time, then at run time,
it looks in a couple places such as the binding.  This is how builders
work, for example.

So the rule is: if an identifier (e.g. foo) is the name of a local
variable that's in scope, then it refers to the local variable.
Otherwise, it's a property.  (Actually, I don't know what happens if it
refers to a field, that may override property as well.)

Best,
Martin

Robert Fischer wrote:

> No: closures refer to variables at the scope where they are defined, not
> where they are called. This is how closures close over variables.
>
> If closures referred to variables at a scope where they were called,
> this code wouldn't work:
>
> def makeClosure() {
>   def printMe = "Hello, World"
>   return { -> println printMe }
> }
>
> def toDo = makeClosure()
> toDo()
>
> But the fact that "printMe" is meaningful when toDo is called is the
> very essence of closures.
>
> The description of scoping on Wikipedia is reasonable:
> http://en.wikipedia.org/wiki/Lexical_scoping
>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Jeff Philp wrote:
>> Hi,
>>
>> Thank you all for your answers.
>>
>> Yes you are right, I was asking about scoping rules primarily, but it
>> was interesting to see the other points raised.
>>
>> What confused me about the scoping rules, was that I understood
>> closures to be compiled segments of code which didn't check the names
>> of variables until the time that they were run.  And that they were
>> run in the environment that called it.
>>
>> So if you refer to my first example
>>
>> // Beginning
>> def closureC = { closureA(); closureB() }
>> def closureA = { println 'closure A' }
>> def closureB = { println 'closure B' }
>>
>> closureC()
>> // End
>>
>> I thought that when closureC was run at the end of the script, that it
>> would be able to see the same variables that would be accessible from
>> the implicit main block of this script.
>>
>> I primarily work with the variables in the binding in scripts that
>> support a Java application, but I have seen the term "property" used
>> to refer to these variables.  I hope this is not a silly question, but
>> could I please seek clarification on the difference between "Property"
>> and "Variable" of a class.
>>
>> Many Thanks,
>> Jeffrey Philp
>>
>> 2009/11/3 Jochen Theodorou <blackdrag@...>:
>>> Roshan Dawrani schrieb:
>>>> Sure?
>>>>
>>>> And how does one define these properties in a script that the closures
>>>> will grab? Can it be done without using binding? Can it be done in
>>>> some way
>>>> that these other vivified properties will be accessible only when
>>>> closures
>>>> themselves as declared as properties but not when they are declared as
>>>> variables?
>>> I think there is a bit confusion here... In a script you cannot really
>>> define/declare properties or fields, only variables. You can assign
>>> values
>>> to what I call dynamic properties. This assignment will kind of
>>> define them,
>>> because the Binding logic will throw an exception if the value has
>>> not been
>>> assigned before. But if you use a different Binding, one that will never
>>> throw the exception, then there is no define/declare.
>>>
>>> On the question on how closureC can access closureA and closureB
>>> before the
>>> Closure part is defined:
>>>
>>> def closureA,closureB
>>> def closureC = { closureA(); closureB() }
>>> closureA = { println 'closure A' }
>>> closureB = { println 'closure B' }
>>>
>>> closureC()
>>>
>>> here closureX is always a local variable, still closureC can access
>>> them. I
>>> should maybe here explain the difference... let us use a java example:
>>>
>>> class Foo {
>>>  Object bar=1;
>>>  void access() {
>>>    System.out.println(bar);
>>>    Object bar=2;
>>>    System.out.println(bar);
>>>  }
>>> }
>>>
>>> This will print first 1, then 2. That is because thee first bar
>>> refers the
>>> field and the second one refers the local variable. The field is then
>>> shadowed by the local variable. In Groovy:
>>>
>>> def x = 1
>>>
>>> will shadow any potential existing field/property of the name x. Thus
>>> if I
>>> have
>>>
>>> x=1
>>> println x
>>> def x = 2
>>> println x
>>>
>>> It would first print 1, then print 2. But the first x is from the
>>> binding,
>>> the second from the local variable. That also means that x is from
>>> the local
>>> variable only after x has been declared. After that it is no longer
>>> possible
>>> to access the property from that scope using just x.
>>>
>>> bye blackdrag
>>>
>>> --
>>> Jochen "blackdrag" Theodorou
>>> The Groovy Project Tech Lead (http://groovy.codehaus.org)
>>> http://blackdragsview.blogspot.com/
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>>   http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>     http://xircles.codehaus.org/manage_email
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>

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

    http://xircles.codehaus.org/manage_email

[Martin C. Martin]

Jeff Philp wrote:
>
> I primarily work with the variables in the binding in scripts that
> support a Java application, but I have seen the term "property" used
> to refer to these variables.  I hope this is not a silly question, but
> could I please seek clarification on the difference between "Property"
> and "Variable" of a class.

There's no Variable of a class, a variable is a local variable in a
method.  In a Groovy script, all the code that isn't in an explicit
method is gathered up and put in a run() method.  When you use "def" in
a script, you're creating a local variable in that method.

When you don't use def, you're not creating anything.  Instead, you're
accessing a property on the current object.  In other words, this code:

def foo = 23
println foo
bar = 55
println bar

is equivalent to this code:

void run() {
    Object foo = 23
    println foo
    this.bar = 55
    println this.bar
}

Which is roughly equivalent to this Java code:

class MyScript extends Script {
    public void run() {
       Object foo = 23;
       System.out.println(foo);
       this.getMetaclass().setProperty("bar", 55);
       System.out.println(this.getMetaclass().getProperty("bar");
    }
}

Best,
Martin

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

    http://xircles.codehaus.org/manage_email