Two questions related to the new MOP

[tugwilson]

Blackdrag and I have been discussing the new MOP: http://
servlet.uwyn.com/drone/log/hausbot/groovy

It would simplify the task of implementing this if we imposed two  
restrictions:

1/ Java allows a method on Class A to call a protected method on  
class B if classes A and B are in the same package. If we allowed  
this it would require some nasty reflection hacks in the metaclass. I  
propose that we do not allow it (classes can still call protected  
methods on their superclasses, of course).

2/ Java allows a class to access private methods on objects with the  
same type. In Groovy we will only allow this when the object is typed:

class C {
   private foo() {
   }

   public x() {
     def a = new C()
     def b = new C()

     a.foo() // fails at run time
     b.foo() // works
   }
}

Comments on these proposals most welcome.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[graemer]

On 6/20/06, John Wilson <tug@...> wrote:

> Blackdrag and I have been discussing the new MOP: http://
> servlet.uwyn.com/drone/log/hausbot/groovy
>
> It would simplify the task of implementing this if we imposed two
> restrictions:
>
> 1/ Java allows a method on Class A to call a protected method on
> class B if classes A and B are in the same package. If we allowed
> this it would require some nasty reflection hacks in the metaclass. I
> propose that we do not allow it (classes can still call protected
> methods on their superclasses, of course).
>
> 2/ Java allows a class to access private methods on objects with the
> same type. In Groovy we will only allow this when the object is typed:
>
> class C {
>    private foo() {
>    }
>
>    public x() {
>      def a = new C()
>      def b = new C()
>
>      a.foo()    // fails at run time
>      b.foo() // works
>    }
> }

Surely the above should be?

      def a = new C()
      C b = new C()

      a.foo()    // fails at run time
      b.foo() // works

Graeme
:

>
> Comments on these proposals most welcome.
>
>
> John Wilson
> The Wilson Partnership
> web http://www.wilson.co.uk
> blog http://eek.ook.org
>
>
>
> ---------------------------------------------------------------------
> 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

[Dierk König]

> 1/ Java allows a method on Class A to call a protected method on  
> class B if classes A and B are in the same package. If we allowed  
> this it would require some nasty reflection hacks in the metaclass. I  
> propose that we do not allow it (classes can still call protected  
> methods on their superclasses, of course).

Ok if we generally interpret 'protected' as 'subclass access only', i.e.
enforce the same rule for field access.

At first it seems a bit limiting but in corner cases one can still
use a Java delegate class.

> 2/ Java allows a class to access private methods on objects with the  
> same type. In Groovy we will only allow this when the object is typed:

Ok. I would even prefer the more restrictive Ruby rule and allow
private access only from within the same object. Wouldn't that be also
easier to implement?

cheers
Mittie

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

    http://xircles.codehaus.org/manage_email

[Jochen Theodorou]

Dierk Koenig schrieb:
[...]
>> 2/ Java allows a class to access private methods on objects with the  
>> same type. In Groovy we will only allow this when the object is typed:
>
> Ok. I would even prefer the more restrictive Ruby rule and allow
> private access only from within the same object. Wouldn't that be also
> easier to implement?

yes ;)

bye blackdrag

--
Jochen Theodorou
Groovy Tech Lead

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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 20 Jun 2006, at 15:42, Graeme Rocher wrote:

> Surely the above should be?
>
>      def a = new C()
>      C b = new C()
>
>      a.foo()    // fails at run time
>      b.foo() // works
>
> Graeme


Yes!

Sorry for the typo.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 20 Jun 2006, at 16:01, Dierk Koenig wrote:

> Ok. I would even prefer the more restrictive Ruby rule and allow
> private access only from within the same object. Wouldn't that be also
> easier to implement?

Yes it would.


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email

[tugwilson]

On 20 Jun 2006, at 16:11, Jochen Theodorou wrote:

> Dierk Koenig schrieb:
> [...]
>>> 2/ Java allows a class to access private methods on objects with  
>>> the  same type. In Groovy we will only allow this when the object  
>>> is typed:
>> Ok. I would even prefer the more restrictive Ruby rule and allow
>> private access only from within the same object. Wouldn't that be  
>> also
>> easier to implement?


We do have some odd corner cases with closures

class C {
   private foo () {}

   public x() {
     def c = { foo()} // need access to private methods from within  
this closure
   }
}

We can hide the nastiness needed to do this inside the Closure's  
metaClass


John Wilson
The Wilson Partnership
web http://www.wilson.co.uk
blog http://eek.ook.org



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

    http://xircles.codehaus.org/manage_email