Dierk Koenig | 6 May 12:17 2006

multiple classes in file, which to execute?

Hi,

question about the GLS:

with multiple class declarations in a file and calling
 groovy filename
which class is supposed to be called
- the first one declared
- the one that's named after the file
?

Now the Groovy trivia: which one is currently chosen?

;-)

cheers
Mittie

Guillaume Laforge | 7 May 15:15 2006
Picon

Re: [groovy-dev] Questions about the road map

Hello all,

Thanks a lot Scott for reminding me about updating the roadmap!
It's been a while since I haven't updated it.
Sorry in advance for the list cross-post.

As Jochen explained, the new MOP is definitely something we want to
include in RC-1, as well as the property replacement proposal. Since
the MOP is a pretty long and big task, I think we'll be releasing a
new JSR-x version (JSR-06) to create a bug-fix release, plus
eventually the property proposal. And RC-1 will contain other bug
fixes and the new MOP.

I've gathered everything on the roadmap page, including the things we
plan on working or evaluating for Groovy 2.0. Nothing's set in stone
for the future though. Here it is:

http://groovy.codehaus.org/Roadmap

On 5/5/06, Scott Hickey <jshickey@...> wrote:
>
> Earlier this week, I gave a presentation on Groovy to a local user's group.
> A question came up about the roadmap. I know that those dates were pretty
> aggressive. I might be a good idea to update the estimates for RC1.
>
>  Along those lines,  is it still the plan to include the new MOP for 1.0? If
> so, should this be part of RC1? If it represents a major change, I would
> think that it probably should be part of RC1.
>  Scott
>
(Continue reading)

Guillaume Laforge | 22 May 22:39 2006
Picon

[jsr] Getting back to business!

Hello dear users, contributors and developers,

Welcome back to the Groovy mailing lists!

As you will probably have noticed, the entire Codehaus site has
suffered a major crash and has been down for more than a week. Both
Bob and Ben (from the Codehaus team) have been working long hours to
recover the system from backups and things are beginning to come
together again.

The JIRA system and the lists are working. The website sometimes works
and sometimes doesn't, but it should be working soon full time --
still a problem with Confluence some times.

The CVS system is still being rebuilt and when it comes back we will
have to spend some time in bringing it up to date. This should not
take more than a couple of days. If you have commit access to the CVS
repository please do not try to commit anything new until we have
restored the repository to the state it was before the crash.

We apologise for the interruption in service but we expect to be fully
recovered by the end of this week.

Thanks a lot for your patience and sorry for the inconvenience.

Let's groove again!

--

-- 
Guillaume Laforge
Groovy Project Manager
(Continue reading)

Ray Cromwell | 29 May 09:58 2006

Categories and Closures


The following example doesn't work (MissingMethodException), but this 
seems to violate both the principle of least surprise and the basic 
definition of a closure (closed over all free variables, bound variables 
must survive loss of the context in which the closure was defined)

class cat
{
   static String xyz(String s) { return "xyz"+s }
}

def c
use(cat)
{
   c={ print it.xyz() }

}

c("Hello World")

Although you could argue that this is a method binding, one could 
replace the category with a getXyz() and bind the closure to the 
variable "it.xyz" instead. Either way, I feel that the closure should be 
closed over all free variables, including meta/pseudo-variables and 
methods which are created by categories.

IMHO, the closure should execute regardless of the context in which it 
is executed. That means that compiled closures should have some idea of 
the scope of categories that existed when they were created.

(Continue reading)

Dierk Koenig | 29 May 10:08 2006

RE: Categories and Closures

It is by design that outside the 'use' closure, the category
methods are not available.

cheers
Mittie

> -----Original Message-----
> From: news [mailto:news@...]On Behalf Of Ray Cromwell
> Sent: Montag, 29. Mai 2006 9:59
> To: jsr@...
> Subject: [groovy-jsr] Categories and Closures
> 
> 
> 
> The following example doesn't work (MissingMethodException), but this 
> seems to violate both the principle of least surprise and the basic 
> definition of a closure (closed over all free variables, bound variables 
> must survive loss of the context in which the closure was defined)
> 
> 
> class cat
> {
>    static String xyz(String s) { return "xyz"+s }
> }
> 
> def c
> use(cat)
> {
>    c={ print it.xyz() }
> 
(Continue reading)

Ray Cromwell | 29 May 10:15 2006

Re: Categories and Closures

Dierk Koenig wrote:
> It is by design that outside the 'use' closure, the category
> methods are not available.
> 

   And what is the reasoning for this design? The fact that a bound 
variable can disappear after you go out of scope rubs me the wrong way. 
I find this behavior "surprising".

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

    http://xircles.codehaus.org/manage_email

Dierk Koenig | 29 May 10:32 2006

RE: Re: Categories and Closures

Categories have a cross-cutting nature like AOP.
This can potentially cut deeper and wider than you whish.
To safeguard from that danger, the effect is limited to the
execution of the closure that is send to the use(cat) method.

I don't understand why you think this would have anyhing 
to do with binding variables. Remember that reference resolution
happens at runtime.

cheers
Mittie

> -----Original Message-----
> From: news [mailto:news@...]On Behalf Of Ray Cromwell
> Sent: Montag, 29. Mai 2006 10:15
> To: jsr@...
> Subject: [groovy-jsr] Re: Categories and Closures
> 
> 
> Dierk Koenig wrote:
> > It is by design that outside the 'use' closure, the category
> > methods are not available.
> > 
> 
>    And what is the reasoning for this design? The fact that a bound 
> variable can disappear after you go out of scope rubs me the wrong way. 
> I find this behavior "surprising".
> 
> 
> ---------------------------------------------------------------------
(Continue reading)

Ray Cromwell | 29 May 10:55 2006

Re: Categories and Closures


Because it can lead to hard to track down bugs. A closure is 
traditionally self contained and does not depend on calling context for 
its environment except for parameter arguments.

Now according to your design, it happens that closures returned from 
methods, possibly deep within a library module, may or may not execute 
properly, unless clear documentation warns you to use the proper 
category. This makes closures less portable.

Dierk Koenig wrote:
> Categories have a cross-cutting nature like AOP.
> This can potentially cut deeper and wider than you whish.
> To safeguard from that danger, the effect is limited to the
> execution of the closure that is send to the use(cat) method.
> 
> I don't understand why you think this would have anyhing 
> to do with binding variables. Remember that reference resolution
> happens at runtime.

mymethod()
{
   def c
   use(foo)
   {
     def someobject=...
     c = {  someobject.xxx + 10 }
   }

   return c
(Continue reading)

Ray Cromwell | 29 May 11:07 2006

Re: Categories and Closures


BTW, before this turns into a huge debate, I have no problem leaving the 
design as is, but I think this needs to be documented, since IMHO it is 
"surprising", and warn programmers of idioms that could lead to buggy or 
surprising behavior if you don't know what you're doing.

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

    http://xircles.codehaus.org/manage_email

Dierk Koenig | 29 May 11:44 2006

RE: Re: Categories and Closures

This hasn't really much to do with closures.

The design of how to use Categories applies equally to every
code, be it closures, methods, scripts, builders, whatever.

If your code relies on a certain context which is not there
at execution time, you'll get an error.

Interestingly enough, you don't even have to define your
closure inside the category:

----
class Cat
{
   static String xyz(String s) { return "xyz"+s }
}

def c = { print it.xyz() }

use(Cat)
{
   c("Hello World")
}
----

BTW: this is more a discussion for the groovy-user list.

cheers
Mittie

(Continue reading)


Gmane