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

[Jochen Theodorou]

[hidden email] schrieb:
[...]
> Here is an exmple:
>
> def x = 3
> println x     // Good here.
> binding.@variables = null
> println x     // What happens here?

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.

bye blackdrag

[Jochen Theodorou]

Jochen Theodorou schrieb:
[...]
> 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.

ah crap somehow used the wrong posting to reply to...  so please ignore
the citation from Kims posting in my former posting and concentrate on
the (im)mutability of String and Integer.

bye blackdrag

[tugwilson]

On 2 Nov 2005, at 07:35, [hidden email] wrote:

>>> This example show that the protected native method close() can  
>>> not be
>>> accessed at other classes.
>>> What is the current state/plan to access a private method ?
>>
>> No it shows that clone() was called on Object. The implementation of
>> clone() on Object throws CloneNotSupportedException.
>>
>>
>
> No, it is a Cloneable problem.
> For Java case, it gives the compile time exception.

Quite so.

You said that "native method close() can not accessed at other  
classes." I assume you meant to type clone() not close().

So clone() can be accessed from other classes. This is unlike Java  
but then Groovy *is* unlike Java:)

In Java this would cause a compile time error. In Groovy it causes a  
run time error. It's a feature of dynamic languages like Groovy that  
you tend to get errors at run time not at compile time.

There is an ongoing debate in the programming community as to whether  
this is a good or bad thing. In many circumstances I don't think it's  
a bad thing that's why I'm interested in Groovy.


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

[tugwilson]

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;)


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

[Jochen Theodorou]

John Wilson schrieb:

[...]
> As switch is not needed - I have already added the ability to have  per
> class custom MetaClasses.

this will surely help, yes. The important point is that access to
private members from outside should be disallowed by default I think.

For unit testing you can still set a predefined MetaClass which allows
that.

bye blackdrag

[tugwilson]

On 2 Nov 2005, at 18:55, Jochen Theodorou wrote:

> this will surely help, yes. The important point is that access to  
> private members from outside should be disallowed by default I think.
>
> For unit testing you can still set a predefined MetaClass which  
> allows that.


Yes I think that the problems of allowing access to private by  
default are too great. This does mean that the compiler will have to  
implement the subset of access checks that we discussed before and  
then generate bytecodes for private access.



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

[Jochen Theodorou]

John Wilson schrieb:

[...]
> Yes I think that the problems of allowing access to private by  default
> are too great. This does mean that the compiler will have to  implement
> the subset of access checks that we discussed before and  then generate
> bytecodes for private access.

how does such bytecode look like? not the real code, but pseudocode...

bye blackdrag

[tugwilson]

On 2 Nov 2005, at 19:09, Jochen Theodorou wrote:

> John Wilson schrieb:
>
> [...]
>> Yes I think that the problems of allowing access to private by  
>> default are too great. This does mean that the compiler will have  
>> to  implement the subset of access checks that we discussed before  
>> and  then generate bytecodes for private access.
>
> 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.

You remember we discussed what static checking rules the compiler  
could enforce when acessing private items? It was on this list or the  
jsr list.

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

[Russel Winder]

On Wed, 2005-11-02 at 19:55 +0100, Jochen Theodorou wrote:

> For unit testing you can still set a predefined MetaClass which allows
> that.

Apologies I haven't been able to follow this discussion in detail but it
strikes me that Groovy now has a full MOP basically a la Smalltalk.  Is
this right or have I misinterpreted?

There will have to be some pages on how to do this testing.  I suspect
that Groovy's ability to test private methods could be a good angle for
Groovy in this niche area.

--
Russel.
====================================================
Dr Russel Winder                [phone]
41 Buckmaster Road              [phone]
London SW11 1EN, UK             [hidden email]

[tugwilson]

On 2 Nov 2005, at 19:21, Russel Winder wrote:

>> For unit testing you can still set a predefined MetaClass which  
>> allows
>> that.
>
> Apologies I haven't been able to follow this discussion in detail  
> but it
> strikes me that Groovy now has a full MOP basically a la  
> Smalltalk.  Is
> this right or have I misinterpreted?

Well, you can replace the standard MetaClass for an arbitrary class  
with an arbitrary MetaClass. This is new and is only in CVS HEAD.  
This has been discuss-wed on this list but it's easy to miss stuff:)
Look for the thread "One MataClass or many?" staring on 18th October.

I'm nervous about claiming that anything is just like Smalltalk -  
that's fighting talk for some folk;)

>
> There will have to be some pages on how to do this testing.  I suspect
> that Groovy's ability to test private methods could be a good angle  
> for
> Groovy in this niche area.

Yes - whilst you can do this now by writing your own MetaClass it'd a  
bit of a pain. I'm in the middle of a major MetaClass restructure and  
at the end of that we should have the tools to make a custom  
metaClass which exposes private methods a trivial matter.


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