Martin C. Martin | 1 Dec 02:47 2009

Re: [groovy-user] Why is this method compiled to a varargs method?

It's part of the general philosophy of dynamic languages.  Statically 
typed languages make you express a lot of intentions, e.g. what types 
the compiler should consider a variable to be.  Dynamic languages 
generally allow an expression where there's a reasonable possible 
interpretation.  So, for example, you don't need a return statement in 
Groovy: if the last expression in a class has non-void type, Groovy 
figures it will just return that value without the programmer needing to 
express his or her intention.  And if it isn't the right type, Groovy 
will convert it, even going so far as to convert one Collection type 
into another, all without a cast or even a return type.

Best,
Martin

Peter Niederwieser wrote:
> Choosing ... over [] conveys an intention. Why doesn't Groovy respect this?
> In other words, why is a Groovy method with an array parameter presented as
> a vararg method to Java and reflection? (For Spock's mocking support, it
> would be very beneficial to know the programmer's intention.)
> 
> Cheers,
> Peter
> 
> 
> Jochen Theodorou wrote:
>> Peter Niederwieser schrieb:
>>> def foo(String[] s) {}
>>> println getClass().getMethod("foo", String[]).isVarArgs() // output: true
>>>
>>> Is this intentional?
(Continue reading)

Merlyn Albery-Speyer | 1 Dec 03:33 2009
Picon

Re: [groovy-user] getProperty delegation

Hi Luke,

Yes. It would appear that there's a problem delegating to a delegate
-- even without getProperty in the mix:

class C {
   <at> Delegate B b = new B()

  static void main(args) {
    def c = new C()

    assert c.someMethod() == "aValue"
  }
}

class B {
   <at> Delegate A a = new A()
}

class A {
  String someMethod() {
  	return "aValue"
  }
}

$ groovy delegation.groovy
Caught: groovy.lang.MissingMethodException: No signature of method:
C.someMethod() is applicable for argument types: () values: []
	at C.main(delegation.groovy:7)

(Continue reading)

Fred Janon | 1 Dec 07:03 2009
Picon

Re: [groovy-user] Support for Calendar range?

Here it is, with credits to Tim for the code

http://jira.codehaus.org/browse/GROOVY-3916

Fred

On Mon, Nov 30, 2009 at 16:59, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
No JIRA created yet, feel free.


On Mon, Nov 30, 2009 at 07:01, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Did someone open a JIRA? Or should I do it?

Thanks

Fred


On Fri, Nov 27, 2009 at 22:02, Felipe Cypriano <fmclists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Why not convert a Calendar to Date and use date range? The implementation would be just a "wrapper".

---
Felipe Cypriano



On Fri, Nov 27, 2009 at 11:29 AM, Tim Yates <tim.yates-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
With calendar being mutable, I have to create a new one every time (with the clone() call), and Calendar is quite an expensive object

Might be better to stick with doing a range of dates

Tim


On Fri, Nov 27, 2009 at 11:33 AM, Guillaume Laforge <glaforge <at> codehaus.org> wrote:
Patch welcome :-)

On Fri, Nov 27, 2009 at 12:29, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>calendarDateOne..calendarDateTwo
>
> Yes, exactly that.
>
> Fred
>
>
> On Fri, Nov 27, 2009 at 16:51, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org>
> wrote:
>>
>> On Fri, Nov 27, 2009 at 08:47, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Is there (already or planned) support for a Calendar range to be able to
>> > define Calendar ranges the same way Date ranges exist already with a day
>> > increment?
>>
>> Can you be a bit more explicit on what exactly you'd like to see?
>> If it's something like calendarDateOne..calendarDateTwo, yeah, that
>> would be neat to have, indeed.
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email








--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

Tim Yates | 1 Dec 07:31 2009
Picon

Re: [groovy-user] Support for Calendar range?

Cool.

Hope I don't get a ton of spam from having my email address in the issue though :-/

Tim

On Tue, Dec 1, 2009 at 6:03 AM, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Here it is, with credits to Tim for the code

http://jira.codehaus.org/browse/GROOVY-3916

Fred


On Mon, Nov 30, 2009 at 16:59, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
No JIRA created yet, feel free.


On Mon, Nov 30, 2009 at 07:01, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Did someone open a JIRA? Or should I do it?

Thanks

Fred


On Fri, Nov 27, 2009 at 22:02, Felipe Cypriano <fmclists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Why not convert a Calendar to Date and use date range? The implementation would be just a "wrapper".

---
Felipe Cypriano



On Fri, Nov 27, 2009 at 11:29 AM, Tim Yates <tim.yates-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
With calendar being mutable, I have to create a new one every time (with the clone() call), and Calendar is quite an expensive object

Might be better to stick with doing a range of dates

Tim


On Fri, Nov 27, 2009 at 11:33 AM, Guillaume Laforge <glaforge <at> codehaus.org> wrote:
Patch welcome :-)

On Fri, Nov 27, 2009 at 12:29, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>calendarDateOne..calendarDateTwo
>
> Yes, exactly that.
>
> Fred
>
>
> On Fri, Nov 27, 2009 at 16:51, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org>
> wrote:
>>
>> On Fri, Nov 27, 2009 at 08:47, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Is there (already or planned) support for a Calendar range to be able to
>> > define Calendar ranges the same way Date ranges exist already with a day
>> > increment?
>>
>> Can you be a bit more explicit on what exactly you'd like to see?
>> If it's something like calendarDateOne..calendarDateTwo, yeah, that
>> would be neat to have, indeed.
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email








--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


Fred Janon | 1 Dec 07:56 2009
Picon

Re: [groovy-user] Support for Calendar range?

Sorry Tim, copied from the browser and didn't realize. Maybe Guillaume can edit the issue and remove your email.

Fred

On Tue, Dec 1, 2009 at 14:31, Tim Yates <tim.yates-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Cool.

Hope I don't get a ton of spam from having my email address in the issue though :-/

Tim


On Tue, Dec 1, 2009 at 6:03 AM, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Here it is, with credits to Tim for the code

http://jira.codehaus.org/browse/GROOVY-3916

Fred


On Mon, Nov 30, 2009 at 16:59, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
No JIRA created yet, feel free.


On Mon, Nov 30, 2009 at 07:01, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Did someone open a JIRA? Or should I do it?

Thanks

Fred


On Fri, Nov 27, 2009 at 22:02, Felipe Cypriano <fmclists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Why not convert a Calendar to Date and use date range? The implementation would be just a "wrapper".

---
Felipe Cypriano



On Fri, Nov 27, 2009 at 11:29 AM, Tim Yates <tim.yates-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
With calendar being mutable, I have to create a new one every time (with the clone() call), and Calendar is quite an expensive object

Might be better to stick with doing a range of dates

Tim


On Fri, Nov 27, 2009 at 11:33 AM, Guillaume Laforge <glaforge <at> codehaus.org> wrote:
Patch welcome :-)

On Fri, Nov 27, 2009 at 12:29, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>calendarDateOne..calendarDateTwo
>
> Yes, exactly that.
>
> Fred
>
>
> On Fri, Nov 27, 2009 at 16:51, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org>
> wrote:
>>
>> On Fri, Nov 27, 2009 at 08:47, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Is there (already or planned) support for a Calendar range to be able to
>> > define Calendar ranges the same way Date ranges exist already with a day
>> > increment?
>>
>> Can you be a bit more explicit on what exactly you'd like to see?
>> If it's something like calendarDateOne..calendarDateTwo, yeah, that
>> would be neat to have, indeed.
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email








--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one



Merlyn Albery-Speyer | 1 Dec 08:34 2009
Picon

Re: [groovy-user] Support for Calendar range?

Hey Fred,

Nice! The code for additional methods like will need to be written in Java. Take a crack at it. The class to add the method to is in src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java. It's here in fisheye:

http://fisheye.codehaus.org/browse/~raw,r=18277/groovy/trunk/groovy/groovy-core/src/main/org/codehaus/groovy/runtime/DefaultGroovyMethods.java

Your methods would have a signature like this:

public static Calendar next(Calendar self) { //...

Cheers,
Merlyn

On Nov 30, 2009, at 10:03 PM, Fred Janon wrote:

Here it is, with credits to Tim for the code

http://jira.codehaus.org/browse/GROOVY-3916

Fred

On Mon, Nov 30, 2009 at 16:59, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
No JIRA created yet, feel free.


On Mon, Nov 30, 2009 at 07:01, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Did someone open a JIRA? Or should I do it?

Thanks

Fred


On Fri, Nov 27, 2009 at 22:02, Felipe Cypriano <fmclists-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Why not convert a Calendar to Date and use date range? The implementation would be just a "wrapper".

---
Felipe Cypriano



On Fri, Nov 27, 2009 at 11:29 AM, Tim Yates <tim.yates-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
With calendar being mutable, I have to create a new one every time (with the clone() call), and Calendar is quite an expensive object

Might be better to stick with doing a range of dates

Tim


On Fri, Nov 27, 2009 at 11:33 AM, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org> wrote:
Patch welcome :-)

On Fri, Nov 27, 2009 at 12:29, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>calendarDateOne..calendarDateTwo
>
> Yes, exactly that.
>
> Fred
>
>
> On Fri, Nov 27, 2009 at 16:51, Guillaume Laforge <glaforge-yCVjj/EcxBJg9hUCZPvPmw@public.gmane.org>
> wrote:
>>
>> On Fri, Nov 27, 2009 at 08:47, Fred Janon <fjanon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> > Is there (already or planned) support for a Calendar range to be able to
>> > define Calendar ranges the same way Date ranges exist already with a day
>> > increment?
>>
>> Can you be a bit more explicit on what exactly you'd like to see?
>> If it's something like calendarDateOne..calendarDateTwo, yeah, that
>> would be neat to have, indeed.
>>
>>
>> --
>> Guillaume Laforge
>> Groovy Project Manager
>> Head of Groovy Development at SpringSource
>> http://www.springsource.com/g2one
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>



--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one

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

   http://xircles.codehaus.org/manage_email








--
Guillaume Laforge
Groovy Project Manager
Head of Groovy Development at SpringSource
http://www.springsource.com/g2one


Daniel López | 1 Dec 08:42 2009
Picon
Picon

Re: [groovy-user] Java and Groovy?

Hi Ashley,
I'm afraid I cannot tell you much about JavaRebel working with Groovy as 
we don't use it. We execute Groovy through the Java Scripting API so we 
don't have to resort to that. And when playing with Java or compiled 
Groovy files, Java 6 hot swapping is enough for us so, I have no 
experience with mixing JavaRebel and Groovy.

S!
D.

Ashley Aitken escribió:
> 
> Thanks Daniel.
> 
> I came to that conclusion as well, and even found JavaRebel (which looks 
> good).
> 
> I wonder how well JavaRebel works with Groovy?  I see some mention of it 
> working ...
> 
> Cheers,
> Ashley.
> 
> On 30/11/2009, at 4:00 PM, Daniel López wrote:
> 
>> Ashley Aitken escribió:
>> ...
>>> I am hoping for an application just to be able to run with regular 
>>> Java and Groovy compiled files, but if/when the Groovy source files 
>>> are edited the classes will *automatically* be reloaded when needed.
>> ...
>> "Groovy compiled files" are standard .class files so they have the 
>> same issues as Java classes regarding to reloading of new versions, 
>> classloaders etc. So, in order to reload the changes *automatically* 
>> without restrictions, one has to use the Scripting Engine. But of 
>> course that does not allow you to call the Groovy classes from Java 
>> directly.
>>
>> So, AFAIK, I'm afraid you cannot have both things at the same time. 
>> You might want to try JavaRevel or similar to improve .class reloading 
>> but it comes with some restrictions.
>>
>> S!
>> D.

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

    http://xircles.codehaus.org/manage_email

Jochen Theodorou | 1 Dec 08:53 2009
Picon

Re: [groovy-user] mixing dynamic and static code in groovy

Alex Tkachman schrieb:
> On Mon, Nov 30, 2009 at 11:54 PM, Jochen Theodorou <blackdrag@...> wrote:
>> Alex Tkachman schrieb:
>>> Hi!
>>>
>>> After I published 1st results in to direction of statically typed
>>> Groovy I was asked many times by different people about ability to mix
>>> dynamic and static code together. Here is short article on first
>>> results in this direction -
>>> http://groovy.dzone.com/articles/mixing-dynamic-and-static-code-0
>> Alex, you wrote: number ([value: it, prime:false]
>> Is there a special reason you don't write:
>>
>> number (value: it, prime:false)?
>>
>> Becuase, this version is what we usually use. Yours is not wrong, I was just
>> wondering.
>>
> 
> Good catch. Not implemented yet and I try not publish code, which doesn't work.

Should I take this as you writing a whole new parser then?

[...]
>>  And even if I know it is a Collection, that does not
>> remove the possibility that the value has a class with its own definition of
>> "each" which then should be called instead. And I am not talking about a
>> dynamic "each" method here.
> 
> resolve of method to call goes very similar to standard groovy
> algorithm - own methods, DGM, static categories in use but dynamicly
> added methods obviously ignored

ok, then if there is:

Collection x = foo()

and foo() is a dynanic method call, and later we have

x.each {println it}

how are you able to tell what "each" exactly is to be used without 
making a dynamic method call for it? In Java this is out of question, 
because either it is defined on Collection in a static manner (which is 
not), or it is a compile time error. So I wonder how you want to make 
this into a static method call.

Also the order own methods, DGM is not fully correct. If we have a 
method T#x() in DGM (DGM#x(T)) as well as in T, then the DGM method is 
used instead of the one defined on T. If we have a method x() in T1, but 
the class we actually have to handle is T2 extends T1, and DGM provides 
a T2#x(), then the DGM method is taking instead of the own method again. 
   If we actually handle a T3 extends T2 and there is a T3#x(), then 
T3#x() will be used instead of the DGM method. And these rules apply 
even if the static type of the variable used for the value laterhas only 
the static type T0, with T0 extends T1.

I really wonder how you want to handle T0 x = foo(); x.x(), if x is 
actually a T2. Don't get me wrong, I can imagine ways, they are just not 
very good.

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

Jochen Theodorou | 1 Dec 08:59 2009
Picon

Re: [groovy-user] Why is this method compiled to a varargs method?

Peter Niederwieser schrieb:
> Choosing ... over [] conveys an intention. Why doesn't Groovy respect this?
> In other words, why is a Groovy method with an array parameter presented as
> a vararg method to Java and reflection? (For Spock's mocking support, it
> would be very beneficial to know the programmer's intention.)

In my opinion the Java designer here faced the problem that a program 
that did not compiler before could suddenly compile. IMHO this is the 
only reason they made this array varargs dualism. Besides backwards 
compatibility I see no reason for this logic and I am unclear what 
intention a programmer could have to make such an method not varargs. 
Maybe you know?

Plus for Groovy we supported this stuff even though we had been not 
under java5 that time. Back then it was to either support varargs, with 
a Groovy only solution or not at all.

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

Alex Tkachman | 1 Dec 09:18 2009
Picon

Re: [groovy-user] mixing dynamic and static code in groovy

>>
>> Good catch. Not implemented yet and I try not publish code, which doesn't
>> work.
>
> Should I take this as you writing a whole new parser then?
>

Of course not. I simply don't compile yet NamedArgumentListExpression.

> [...]
>>>
>>>  And even if I know it is a Collection, that does not
>>> remove the possibility that the value has a class with its own definition
>>> of
>>> "each" which then should be called instead. And I am not talking about a
>>> dynamic "each" method here.
>>
>> resolve of method to call goes very similar to standard groovy
>> algorithm - own methods, DGM, static categories in use but dynamicly
>> added methods obviously ignored
>
> ok, then if there is:
>
> Collection x = foo()
>
> and foo() is a dynanic method call, and later we have
>
> x.each {println it}
>

Let see we have

def foo () {...}

Collection x = foo ()

x.each { println x }

what I do is

Collection x = (Collection)foo ()

I didn't decide yet should it be just cast or dynamic coersion. Both
options have pros and contras and trivial to implement

then

SpecialDGM.each ( x, { println x } )

where

SpecialDGM.each (Iterable<T> self, Function1<T,?> closure)

> how are you able to tell what "each" exactly is to be used without making a
> dynamic method call for it? In Java this is out of question, because either
> it is defined on Collection in a static manner (which is not), or it is a
> compile time error. So I wonder how you want to make this into a static
> method call.
>
> Also the order own methods, DGM is not fully correct. If we have a method
> T#x() in DGM (DGM#x(T)) as well as in T, then the DGM method is used instead
> of the one defined on T. If we have a method x() in T1, but the class we
> actually have to handle is T2 extends T1, and DGM provides a T2#x(), then
> the DGM method is taking instead of the own method again.  If we actually
> handle a T3 extends T2 and there is a T3#x(), then T3#x() will be used
> instead of the DGM method. And these rules apply even if the static type of
> the variable used for the value laterhas only the static type T0, with T0
> extends T1.
>
> I really wonder how you want to handle T0 x = foo(); x.x(), if x is actually
> a T2. Don't get me wrong, I can imagine ways, they are just not very good.
>
> 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


Gmane