Basic method call question...

[Fred Janon]

I just got the follwing error with Groovy 1.6.3. I thought that the argument list was not ambiguous. Is there a way to indicate which method I want to call? Adding (String) didn't help.

Thanks

Fred

Ambiguous method overloading for method NameService#create. Cannot resolve which method to invoke for [null, class java.lang.String, null] due to overlapping prototypes between: [class Language, class java.lang.String, class java.lang.String] [class java.lang.String, class java.lang.String, class java.lang.String]

groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method NameService#create.
Cannot resolve which method to invoke for [null, class java.lang.String, null] due to overlapping prototypes between:
[class Language, class java.lang.String, class java.lang.String]
[class java.lang.String, class java.lang.String, class java.lang.String]
at NameService.create(NameService.groovy)
at DescriptorService.create(DescriptorService.groovy:23)

Here is the call:

def create(String name, String description, String languageabbr)
 {
 ...
  idescription = nameService.create((String)languageabbr, description)
}

and the implementation in NameService:

def create(String langabbr, String content, String description = null)
 {
  ...
 }

def create(Language lang, String content, String description = null)
 {
...

}

[Jochen Theodorou]

Fred Janon schrieb:

> I just got the follwing error with Groovy 1.6.3. I thought that the
> argument list was not ambiguous. Is there a way to indicate which method
> I want to call? Adding (String) didn't help.
> Thanks
> Fred
> Ambiguous method overloading for method NameService#create. Cannot
> resolve which method to invoke for [null, class java.lang.String, null]
> due to overlapping prototypes between: [class Language, class
> java.lang.String, class java.lang.String] [class java.lang.String, class
> java.lang.String, class java.lang.String]

you make a method call NameService.create(a,b,c) with a and c being
null. Now there is create(Language,String,String) and
create(String,String,String). This cannot be resolved by groovy, because
the only argument that would make a difference is the first one, and
that is null, so we don't know the type. Also I suppose the distance to
Object is for String and Language the same. So if you want to repair
that using a cast, then it would for example be:

NameService.create((String)a,b,c)

This would force method selection to use the triple String variant.

> Here is the call:
> def create(String name, String description, String languageabbr)
>  {
>  ...
>   idescription = nameService.create(*(String)languageabbr*, description)
> }

you sure? because the exception says there are 3 arguments, I see only 2.

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

[Fred Janon]

When I call create with 3 arguments with the last one null, it works

  idescription = nameService.create((String)languageabbr, description, null)

but I confirm that with 2 args as indicated in my original email, it fails:

 idescription = nameService.create(*(String)languageabbr*, description)

I don't really understand why it works with 3 args, since the last one has a default of null in the 2 definitions.

Fred

On Thu, Nov 5, 2009 at 12:42, Jochen Theodorou <blackdrag@...> wrote:

Fred Janon schrieb:

I just got the follwing error with Groovy 1.6.3. I thought that the argument list was not ambiguous. Is there a way to indicate which method I want to call? Adding (String) didn't help.
Thanks
Fred
Ambiguous method overloading for method NameService#create. Cannot resolve which method to invoke for [null, class java.lang.String, null] due to overlapping prototypes between: [class Language, class java.lang.String, class java.lang.String] [class java.lang.String, class java.lang.String, class java.lang.String]

you make a method call NameService.create(a,b,c) with a and c being null. Now there is create(Language,String,String) and create(String,String,String). This cannot be resolved by groovy, because the only argument that would make a difference is the first one, and that is null, so we don't know the type. Also I suppose the distance to Object is for String and Language the same. So if you want to repair that using a cast, then it would for example be:

NameService.create((String)a,b,c)

This would force method selection to use the triple String variant.

Here is the call:
def create(String name, String description, String languageabbr)
 {
 ...
 idescription = nameService.create(*(String)languageabbr*, description)
}

you sure? because the exception says there are 3 arguments, I see only 2.

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]

Fred Janon schrieb:
> When I call create with 3 arguments with the last one null, it works
>   idescription = nameService.create((String)languageabbr, description, null)
>
> but I confirm that with 2 args as indicated in my original email, it fails:
>  idescription = nameService.create(*(String)languageabbr*, description)
> I don't really understand why it works with 3 args, since the last one
> has a default of null in the 2 definitions.

but Groovy did not see any method with two parameters or else the
exception message should have been different. let me test:

class X{}
class Y{}


def foo(X x1,X x2,X x3){1}
def foo(Y x1,X x2,X x3){2}

def a = null
def b = new X()
def c = null
foo(a,b,c)

this gives an error messages like you received it. If It try:

foo(a,b)

I get:
No signature of method: test.foo() is applicable for argument types:
(null, X) values: [null, X@1acaf0ed]

So I really wonder.... or is create written in Groovy?

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

[Fred Janon]

All the code is groovy code.

Fred

On Thu, Nov 5, 2009 at 21:36, Jochen Theodorou <blackdrag@...> wrote:

Fred Janon schrieb:

When I call create with 3 arguments with the last one null, it works
 idescription = nameService.create((String)languageabbr, description, null)

but I confirm that with 2 args as indicated in my original email, it fails:
 idescription = nameService.create(*(String)languageabbr*, description)
I don't really understand why it works with 3 args, since the last one has a default of null in the 2 definitions.

but Groovy did not see any method with two parameters or else the exception message should have been different. let me test:

class X{}
class Y{}


def foo(X x1,X x2,X x3){1}
def foo(Y x1,X x2,X x3){2}

def a = null
def b = new X()
def c = null
foo(a,b,c)

this gives an error messages like you received it. If It try:

foo(a,b)

I get:
No signature of method: test.foo() is applicable for argument types: (null, X) values: [null, X@1acaf0ed]

So I really wonder.... or is create written in Groovy?

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

[Martin C. Martin]

I think this is about default values for method parameters.  If you
change your example to:

class X{}
class Y{}


def foo(X x1,X x2,X x3 = null){1}
def foo(Y x1,X x2,X x3 = null){2}

def a = null
def b = new X()
def c = null
println (foo((X)a,b) )


Then you get an error message, but you shouldn't.

Best,
Martin

Jochen Theodorou wrote:

> Fred Janon schrieb:
>> When I call create with 3 arguments with the last one null, it works
>>   idescription = nameService.create((String)languageabbr, description,
>> null)
>>
>> but I confirm that with 2 args as indicated in my original email, it
>> fails:
>>  idescription = nameService.create(*(String)languageabbr*, description)
>> I don't really understand why it works with 3 args, since the last one
>> has a default of null in the 2 definitions.
>
> but Groovy did not see any method with two parameters or else the
> exception message should have been different. let me test:
>
> class X{}
> class Y{}
>
>
> def foo(X x1,X x2,X x3){1}
> def foo(Y x1,X x2,X x3){2}
>
> def a = null
> def b = new X()
> def c = null
> foo(a,b,c)
>
> this gives an error messages like you received it. If It try:
>
> foo(a,b)
>
> I get:
> No signature of method: test.foo() is applicable for argument types:
> (null, X) values: [null, X@1acaf0ed]
>
> So I really wonder.... or is create written in Groovy?
>
> bye blackdrag
>

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Martin C. Martin schrieb:
> I think this is about default values for method parameters.  If you
> change your example to:
>
> class X{}
> class Y{}
>
>
> def foo(X x1,X x2,X x3 = null){1}
> def foo(Y x1,X x2,X x3 = null){2}

true... I recently put in a fix that will uses casts, but I don't know
if only for the optional arg, or for all of them

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

[Fred Janon]

As I mentioned, I am using 1.6.3, since it's the one used in Grails 1.1.1, so I am not sure the changes you mention are in that version. I don't think optional args matter, I have some other methods without them and I have the same issue.

What I don't understand is why we need the cast when the argument passed in the call is typed. So casting seems redundant to me. I would understand that we need casting if the argument was declared with "def arg1" but in my case I specified "String arg1", so the compiler sees already the type at compile time and it's not going to change at run time. I had to cast a whole bunch of calls where I thought that declaring the variable with a type would alleviate the need of casting and also lift the ambiguity, like in Java. Now if I change the argument type, I have to change the cast as well, which carries a big risk if I forget to change the cast.

Thanks for investigating.

Fred

On Fri, Nov 6, 2009 at 00:10, Jochen Theodorou <blackdrag@...> wrote:

Martin C. Martin schrieb:

I think this is about default values for method parameters.  If you change your example to:

class X{}
class Y{}


def foo(X x1,X x2,X x3 = null){1}
def foo(Y x1,X x2,X x3 = null){2}

true... I recently put in a fix that will uses casts, but I don't know if only for the optional arg, or for all of them

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]

Fred Janon schrieb:
> As I mentioned, I am using 1.6.3, since it's the one used in Grails
> 1.1.1, so I am not sure the changes you mention are in that version. I
> don't think optional args matter, I have some other methods without them
> and I have the same issue.

Groovy is a dynamic typed language and method selection is done entirely
at runtime. Null has no predefined type. For example:

Object o = 1
foo(o)

assuming there is foo(Object) and foo(Integer), then Java would choose
foo(Object), but Groovy will always choose foo(Integer), since the
dynamic type is Integer.

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

[Chris Broadfoot]

Yep, this is called multiple dispatch or multimethods...

http://en.wikipedia.org/wiki/Multiple_dispatch

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

> Fred Janon schrieb:
>>
>> As I mentioned, I am using 1.6.3, since it's the one used in Grails 1.1.1,
>> so I am not sure the changes you mention are in that version. I don't think
>> optional args matter, I have some other methods without them and I have the
>> same issue.
>
> Groovy is a dynamic typed language and method selection is done entirely at
> runtime. Null has no predefined type. For example:
>
> Object o = 1
> foo(o)
>
> assuming there is foo(Object) and foo(Integer), then Java would choose
> foo(Object), but Groovy will always choose foo(Integer), since the dynamic
> type is Integer.
>
> 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

[Martin C. Martin]

But what's ambiguous in this case?

class X {}
class Y {}

def foo(X arg1, X arg2 = null) {1}
def foo(Y arg1, X arg2 = null) {2}

foo((X)null)

?

That fails with a compile error, but this succeeds:

foo((X)null, null)

In the first form, why can't the runtime say "I have to treat the first
arg as an X or something derived from X, so the second foo() can't
apply, which leaves only the first foo()"?  That's what it does in the
second case.

Best,
Martin

Jochen Theodorou wrote:

> Fred Janon schrieb:
>> As I mentioned, I am using 1.6.3, since it's the one used in Grails
>> 1.1.1, so I am not sure the changes you mention are in that version. I
>> don't think optional args matter, I have some other methods without
>> them and I have the same issue.
>
> Groovy is a dynamic typed language and method selection is done entirely
> at runtime. Null has no predefined type. For example:
>
> Object o = 1
> foo(o)
>
> assuming there is foo(Object) and foo(Integer), then Java would choose
> foo(Object), but Groovy will always choose foo(Integer), since the
> dynamic type is Integer.
>
> bye blackdrag
>

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

    http://xircles.codehaus.org/manage_email

[samd]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I was wondering if there is a way to change the current working directory from within a Groovy script like you could do with bash?

Asking Google didn't give me too much so I'm guessing it probably isn't possible without some heavy lifting?

Thanks

[Robert Fischer]

There's no way to do this from within Java.  It was one of the concepts thrown overboard in the name
of platform independence.

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

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


Samuel Doyle wrote:
> I was wondering if there is a way to change the current working
> directory from within a Groovy script like you could do with bash?
>
> Asking Google didn't give me too much so I'm guessing it probably isn't
> possible without some heavy lifting?
>
> Thanks

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Martin C. Martin schrieb:
> But what's ambiguous in this case?
>
> class X {}
> class Y {}
>
> def foo(X arg1, X arg2 = null) {1}
> def foo(Y arg1, X arg2 = null) {2}
>
> foo((X)null)

this works in 1.7 beta 2, what exception do you get? As I said there was
a related bug that got fixed, I think 1.6.5 has the fix too

bvye 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

[Paul King]

I have used the dir parameter for ant.exec() with AntBuilder
as a bootstrapping mechanism for this - you can call yourself
with a flag for instance.

Cheers,
Paul.


Samuel Doyle wrote:
> I was wondering if there is a way to change the current working
> directory from within a Groovy script like you could do with bash?
>
> Asking Google didn't give me too much so I'm guessing it probably isn't
> possible without some heavy lifting?
>
> Thanks


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

    http://xircles.codehaus.org/manage_email

[samd]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Hehe, interesting I'm pretty new to Groovy but have been using AntBuilder which is pretty neat.

Wasn't sure if there might have been something available in Groovy or not to do this but seeing it is based off Java then it would make it difficult :).

---

From: Paul King <paulk@...>
To: user@...
Sent: Thu, November 5, 2009 8:47:29 PM
Subject: Re: [groovy-user] Changing working directory


I have used the dir parameter for ant.exec() with AntBuilder
as a bootstrapping mechanism for this - you can call yourself
with a flag for instance.

Cheers,
Paul.


Samuel Doyle wrote:
> I was wondering if there is a way to change the current working directory from within a Groovy script like you could do with bash?
>
> Asking Google didn't give me too much so I'm guessing it probably isn't possible without some heavy lifting?
>
> Thanks


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

  http://xircles.codehaus.org/manage_email

[Martin C. Martin]

The best you can do is start another Java process in the desired
directory, but of course that won't have any of the objects in your
current process.

Best,
Martin

Robert Fischer wrote:

> There's no way to do this from within Java.  It was one of the concepts
> thrown overboard in the name of platform independence.
>
> ~~ Robert Fischer, Smokejumper IT Consulting.
> Enfranchised Mind Blog http://EnfranchisedMind.com/blog
>
> Grails Expert Retainer Services
> http://smokejumperit.com/grails-retainer/
>
>
> Samuel Doyle wrote:
>> I was wondering if there is a way to change the current working
>> directory from within a Groovy script like you could do with bash?
>>
>> Asking Google didn't give me too much so I'm guessing it probably
>> isn't possible without some heavy lifting?
>>
>> Thanks
>
> ---------------------------------------------------------------------
> 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]

I think his example is more like:

def foo(Object x) { "Object" }
def foo(Integer x) { "Integer" }

Integer i = null
foo(i)

In this case, we call foo(Object), even though we know at compile time that the expression type is Integer.  The argument is that, if we know the type of an expression at compile time, the (runtime) method dispatch should work the same as if there was a cast.  So the above expression should be equivalent to:

Integer i = null
foo((Integer) i)

Unfortunately, that will work in fewer places than you might think.  Properties and methods can be changed at runtime by the metaclass, only local variables can't.  So for example:

class Foo {
  Integer i = null
  def run() {
    foo(i) // "i" could be any type, if we've messed with the metaclass before this is executed.
   }
}

And if you don't modify the metaclass, the only case where a runtime value can be more general than the compile time type is null.

Jochen Theodorou wrote:

Fred Janon schrieb:
> As I mentioned, I am using 1.6.3, since it's the one used in Grails
> 1.1.1, so I am not sure the changes you mention are in that version. I
> don't think optional args matter, I have some other methods without them
> and I have the same issue.

Groovy is a dynamic typed language and method selection is done entirely
at runtime. Null has no predefined type. For example:

Object o = 1
foo(o)

assuming there is foo(Object) and foo(Integer), then Java would choose
foo(Object), but Groovy will always choose foo(Integer), since the
dynamic type is Integer.

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

[Martin C. Martin]

You're right, I tested this in an older version.  In 1.7 beta 2 snapshot
it works.

Best,
Martin

Jochen Theodorou wrote:

> Martin C. Martin schrieb:
>> But what's ambiguous in this case?
>>
>> class X {}
>> class Y {}
>>
>> def foo(X arg1, X arg2 = null) {1}
>> def foo(Y arg1, X arg2 = null) {2}
>>
>> foo((X)null)
>
> this works in 1.7 beta 2, what exception do you get? As I said there was
> a related bug that got fixed, I think 1.6.5 has the fix too
>
> bvye blackdrag
>

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

    http://xircles.codehaus.org/manage_email

[samd]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Very basic, I was reading http://jira.codehaus.org/browse/GROOVY-546 which suggested using a wrapper class containing static member variables that you wanted to be globally accessible within a script.

So simply if I do this

class Global {
   static x
}

then later

Global.x = new Something() // can be even just Global.x = "test"

I end up getting Caught: java.lang.ExceptionInInitializerError
I've tried using a primitive type, explicitly defining the type still the same thing happens.

Using Groovy 1.6.5