Re: [groovy-dev] Default access for methods in Groovy

classic Classic list List threaded Threaded
41 messages Options
12345
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

Jochen Theodorou
John Wilson schrieb:
[...]
>> how does such bytecode look like? not the real code, but pseudocode...
>
> Just the normal bytecode which would be generated by the Java  compiler
> for access to the item - the key thing is that the access  does not go
> via the MetaClass when we are accessing private. So the  Groovy compiler
> acts like a Java compiler when accessing private.

only that I don't how that should work...

private bar(Integer i){}
public  bar(String s){}

def foo(o) {
   bar(o)
}

what is the code for calling bar? I thought we don't know enough about
"o" to be sure which method has to be called. And for java you need to
cast to the method you want to have, or do other things like GString
conversion.... or do you intend to put these parts of MetaClass into
here? Sounds bugdriven and difficult to debug for me.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

tugwilson

On 2 Nov 2005, at 20:03, Jochen Theodorou wrote:

> only that I don't how that should work...
>
> private bar(Integer i){}
> public  bar(String s){}
>
> def foo(o) {
>   bar(o)
> }
>
> what is the code for calling bar? I thought we don't know enough  
> about "o" to be sure which method has to be called. And for java  
> you need to cast to the method you want to have, or do other things  
> like GString conversion.... or do you intend to put these parts of  
> MetaClass into here? Sounds bugdriven and difficult to debug for me.


Good point!

I need to thinks some more about this:)

In this case perhaps we need to do something like:


metaclass = getmetaClassfor(this);
params =  
metaclass.eitherCallThemethodOrGiveMeTheParametersToCallThePrivateMethod
("p", new Object[]{o})
if (params != null) {
generate the bytecode to call bar
}

The compiler would have to also deal with deciding which bar to call  
if there were overloaded private bars

Fun stuff!



John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

Jochen Theodorou
John Wilson schrieb:

>
> On 2 Nov 2005, at 20:03, Jochen Theodorou wrote:
>
>> only that I don't how that should work...
>>
>> private bar(Integer i){}
>> public  bar(String s){}
>>
>> def foo(o) {
>>   bar(o)
>> }
>>
>> what is the code for calling bar? I thought we don't know enough  
>> about "o" to be sure which method has to be called. And for java  you
>> need to cast to the method you want to have, or do other things  like
>> GString conversion.... or do you intend to put these parts of  
>> MetaClass into here? Sounds bugdriven and difficult to debug for me.
>
> Good point!
 >
 > I need to thinks some more about this:)

lol ;)

> In this case perhaps we need to do something like:
>
> metaclass = getmetaClassfor(this);
> params =  
> metaclass.eitherCallThemethodOrGiveMeTheParametersToCallThePrivateMethod
> ("p", new Object[]{o})
> if (params != null) {
> generate the bytecode to call bar
> }
>
> The compiler would have to also deal with deciding which bar to call  if
> there were overloaded private bars

that's the point. I am not sure he can. getting the method's Parameter
is no solution because you have to cast to them... I am not sure the
bytecode allows a cast to a class you don't know until runtime. It would
be cool if I am wrong here.

bye blackdrag




> Fun stuff!
>
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

tugwilson

On 2 Nov 2005, at 20:33, Jochen Theodorou wrote:

> that's the point. I am not sure he can. getting the method's  
> Parameter is no solution because you have to cast to them... I am  
> not sure the bytecode allows a cast to a class you don't know until  
> runtime. It would be cool if I am wrong here.


But you *will* know the type. In your example you know to cast to  
Integer.

If you have multiple private methods you will have to ask the  
metaclass which one to call:


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

Jochen Theodorou
John Wilson schrieb:

>
> On 2 Nov 2005, at 20:33, Jochen Theodorou wrote:
>
>> that's the point. I am not sure he can. getting the method's  
>> Parameter is no solution because you have to cast to them... I am  not
>> sure the bytecode allows a cast to a class you don't know until  
>> runtime. It would be cool if I am wrong here.
>
> But you *will* know the type. In your example you know to cast to  Integer.

ah so you want to use a method table as we do with the Reflector - only
directly in the class?

Ok, that works of course. Now I know the implementation ;)

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

phkim
In reply to this post by tugwilson
On Wed, Nov 02, 2005 at 06:25:02PM +0000, John Wilson wrote:

>
> On 2 Nov 2005, at 14:53, Jochen Theodorou wrote:
>
> >I thought about adding a switch to MetaClass when it should be  
> >allowed to access members ignoring the access rules defined by  
> >java. Of course that would mean that, when using that switch,  
> >Integer would be still not immutable, but that's something people  
> >can life with. They have to know what to do when enabling that.
>
>
> As switch is not needed - I have already added the ability to have  
> per class custom MetaClasses. In the future I will be adding custom  
> MetaClasses for String and Integer which disallow these calls. The  
> immutability of Strings and Integers is an important property.
>
> We shoudld note, however, that it's perfectly possible for a Java  
> program to change the value of a String - MetaClass does it and  
> MetaClass is a pure Java class;)

If you use the option "-Djava.security.manager", then
the values of Integer and String are not changed in Java.

Kim

>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

tugwilson

On 4 Nov 2005, at 07:01, [hidden email] wrote:

> If you use the option "-Djava.security.manager", then
> the values of Integer and String are not changed in Java.


And, of course, it has precisely the same effect in Groovy.


John Wilson
The Wilson Partnership
http://www.wilson.co.uk


Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

phkim
On Fri, Nov 04, 2005 at 08:37:07AM +0000, John Wilson wrote:
>
> On 4 Nov 2005, at 07:01, [hidden email] wrote:
>
> >If you use the option "-Djava.security.manager", then
> >the values of Integer and String are not changed in Java.
>
>
> And, of course, it has precisely the same effect in Groovy.

Can you prove it with this groovy code:
X-------------------------------------
def fn(Integer n) {
  n.@value = 10
}

def x = 5
println x    // Print out 5.

fn(x)
println x    // Print out 10.  Is Integer immutable or not?
X------------------------------------------

If you cannot prove it, then
Integer is immutable in Java, but not in Groovy.


Kim


>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

Jochen Theodorou
[hidden email] schrieb:

> On Fri, Nov 04, 2005 at 08:37:07AM +0000, John Wilson wrote:
>
>>On 4 Nov 2005, at 07:01, [hidden email] wrote:
>>
>>>If you use the option "-Djava.security.manager", then
>>>the values of Integer and String are not changed in Java.
>>
>>And, of course, it has precisely the same effect in Groovy.
[...]
> If you cannot prove it, then
> Integer is immutable in Java, but not in Groovy.

but groovy does nothing different than java does with reflection. If the
hint with the security manger is wrong, then it's the same as in groovy
when Java uses reflection. Or the hint with the security manager is not
wrong, then it's the same as in groovy when Java uses Reflection.

bye blackdrag
Reply | Threaded
Open this post in threaded view
|

Re: [groovy-dev] Default access for methods in Groovy

phkim
On Sat, Nov 05, 2005 at 01:58:35AM +0100, Jochen Theodorou wrote:

> [hidden email] schrieb:
>
> >On Fri, Nov 04, 2005 at 08:37:07AM +0000, John Wilson wrote:
> >
> >>On 4 Nov 2005, at 07:01, [hidden email] wrote:
> >>
> >>>If you use the option "-Djava.security.manager", then
> >>>the values of Integer and String are not changed in Java.
> >>
> >>And, of course, it has precisely the same effect in Groovy.
> [...]
> >If you cannot prove it, then
> >Integer is immutable in Java, but not in Groovy.
>
> but groovy does nothing different than java does with reflection. If the
> hint with the security manger is wrong, then it's the same as in groovy
> when Java uses reflection. Or the hint with the security manager is not
> wrong, then it's the same as in groovy when Java uses Reflection.
>
> bye blackdrag

My question is why Integer or String are not immutable in Groovy.

Kim

12345