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?

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)

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

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

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

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

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

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

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

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