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

phkim
On Tue, Nov 01, 2005 at 07:16:09PM +0000, John Wilson wrote:

>
> On 1 Nov 2005, at 17:54, [hidden email] wrote:
>
> >On Tue, Nov 01, 2005 at 06:57:49PM +0000, John Wilson wrote:
> >>
> >>On 1 Nov 2005, at 17:39, [hidden email] wrote:
> >>
> >>>
> >>>How about generators?
> >>
> >>Err yes.... what about generators?
>
> >
> >How does the private/public/protect access work about generators?
>
> Groovy doesn't have generators (unless you consider a Range to be a  
> generator).
>
> I'm sorry but I still don't understand the question
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

Sorry

object creator

Kim
Reply | Threaded
Open this post in threaded view
|

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

tugwilson

On 1 Nov 2005, at 18:10, [hidden email] wrote:

> Sorry
>
> object creator


Constructor?

The constructor seems to be called via the MetaClass but I'm not sure  
if this is always done. there have been discussions in the past of  
things thta can be done by intercepting the constructor call so the  
MetaClass route may be needed.

In the case of the constructor being called as super(....) then I'm  
pretty sure that this must always be done as inline bytecode execution.


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 Tue, Nov 01, 2005 at 07:36:52PM +0000, John Wilson wrote:

>
> On 1 Nov 2005, at 18:10, [hidden email] wrote:
>
> >Sorry
> >
> >object creator
>
>
> Constructor?
>
> The constructor seems to be called via the MetaClass but I'm not sure  
> if this is always done. there have been discussions in the past of  
> things thta can be done by intercepting the constructor call so the  
> MetaClass route may be needed.
>
> In the case of the constructor being called as super(....) then I'm  
> pretty sure that this must always be done as inline bytecode execution.

What is the current state/plan about accessing by "new SomeObject()" ?

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 1 Nov 2005, at 18:34, [hidden email] wrote:

>
> What is the current state/plan about accessing by "new SomeObject()" ?


I have not yet looked in detail at what happens in the current  
MetaClass implementation of invokeConstructor. However, I think it  
handles the constructor invocation in exactly the sae way as a method  
call. That is to say it invokes public constructors via generated  
bytecode and protected ones via reflection.
The work I'm doing on MetaClass is not intended to change the  
behaviour (other than to fix some bugs) but to make the class more  
manageable.


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 Tue, Nov 01, 2005 at 08:43:02PM +0000, John Wilson wrote:

>
> On 1 Nov 2005, at 18:34, [hidden email] wrote:
>
> >
> >What is the current state/plan about accessing by "new SomeObject()" ?
>
>
> I have not yet looked in detail at what happens in the current  
> MetaClass implementation of invokeConstructor. However, I think it  
> handles the constructor invocation in exactly the sae way as a method  
> call. That is to say it invokes public constructors via generated  
> bytecode and protected ones via reflection.
> The work I'm doing on MetaClass is not intended to change the  
> behaviour (other than to fix some bugs) but to make the class more  
> manageable.
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

After testing this simple example:
X----------------------------------------------
class SomeProtectedObject {

     private def obj = null

     private SomeProtectedObject() {
     }

     public SomeProtectedObject(Object o) {
         if (o == null)
             throw new RuntimeException("The parameter o is a null object, but it should be non-null.");
         changeObj(o);
     }

     private void changeObj(Object o) {
         if (o == null)
             throw new RuntimeException("The parameter o is a null object, but it should be non-null.");
         this.obj = o;
     }
}


def y = new SomeProtectedObject("Foo")
println y.@obj

y.changeObj("bar")    // Accessible to a private method changeObj() ?
println y.@obj

def x = new SomeProtectedObject()      // Accessible to a private constructor ?
X-----------------------------------------------

answer to me again.


Kim

Reply | Threaded
Open this post in threaded view
|

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

phkim
In reply to this post by phkim
On Wed, Nov 02, 2005 at 12:02:41AM +0900, [hidden email] wrote:

> On Tue, Nov 01, 2005 at 11:53:44PM +0900, [hidden email] wrote:
> > On Tue, Nov 01, 2005 at 10:46:27PM +0900, [hidden email] wrote:
> > > On Mon, Oct 24, 2005 at 10:21:24PM -0500, LARSON, BRIAN (SBCSI) wrote:
> > > > I found a JIRA issue for this:
> > > > http://jira.codehaus.org/browse/GROOVY-923
> > > > It points to another inconsistency at:
> > > > http://groovy.codehaus.org/Migration+From+Classic+to+JSR+syntax
> > > > Which says:
> > > > The default access level for members of Groovy classes has changed from
> > > > "public" to "protected".
> > > >
> > > > Also, http://groovy.codehaus.org/jsr/spec/Chapter06Names.html says:
> > > > The default access is that a member can be accessed anywhere within the
> > > > package that contains its declaration...
> > > >
> > > >
> > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > *protected in Groovy is the equivalent of both package-protected and
> > > > protected in Java. i.e. you can have friends in the same package - or
> > > > derived classes can also see protected members.
> > > >
> > > > A protected field in Groovy results in a protected access modifier in
> > > > the resulting class.
> > > >
> > > > I tested with the current CVS HEAD and it is the same as JSR-03.
> > > >
> > > > I think class variables should probably be protected or public.  The
> > > > above comment about protected = package + protected is not consistent
> > > > with the implementation and other statements.
> > > >
> > > > If this has been decided, please let me know and I'll correct all these
> > > > conflicting statements and the 923 issue.
> > >
> > > As I know, every access privilege is public in the current Groovy.
> > > That is, private/protected/public/package has no meaning.
> > > Everything is public.
> > >
> > > The current Groovy does not support the encapsulation.
> >
> > Here is an exmple:
> >
> > def x = 3
> > println x     // Good here.
> > binding.@variables = null
> > println x     // What happens here?
> >
> >
> > Kim
> >
>
> Here is another example:
>
> def x = 1..3
> println x                // Good here.  Print out 1..3
> x.each { println it }    // Works fine. Print out 1, 2, and 3
> x.@from = 10
> println x                // Print out 10..3
> x.each { println it }    // Print nothing
>
>
> Kim

Here is another example given by Antti Karanta at Sep 12.

X---------------------------------------
public class CloneExample {
 
  public static void main(String[] args) {
    Object o = new Object();
    Object o2 = o.clone();
  }
 
}
X---------------------------------------

The result is:
Caught: java.lang.CloneNotSupportedException: java.lang.Object
        at CloneExample.main(CloneExample.groovy:5)


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 ?


Kim

>
> > > So Groovy is not an OOP language.
> > >
> > > Here is an sentence from Groovy Home which explains what is Groovy language:
> > >
> > >       Groovy is an agile dynamic language for the Java 2 Platform that
> > >       has many of the features that people like so much
> > >       in languages like Python, Ruby and Smalltalk,
> > >       making them available to Java developers using a Java-like syntax.
> > >
> > >
> > > AFAIK, you should change something there.
> > >
> > >
> > > Kim
> > >
> > > >
> > > > Brian Larson
> > > > SBC
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Wilson [mailto:[hidden email]]
> > > > Sent: Monday, October 24, 2005 4:35 AM
> > > > To: [hidden email]
> > > > Subject: Re: [groovy-dev] Default access for methods in Groovy
> > > >
> > > > On 24 Oct 2005, at 06:11, LARSON, BRIAN (SBCSI) wrote:
> > > > > I'm doing a presentation for work on Groovy and I ran across two pages
> > > > > which
> > > > > conflict concerning the default access for methods in Groovy.
> > > > >
> > > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > >  *methods are private by default and classes public
> > > > > http://groovy.codehaus.org/Scripts+and+Classes says:
> > > > >  One difference with Groovy is that by default things are public  
> > > > > unless
> > > > > you specify otherwise.
> > > > >
> > > > > I tested it to be sure (with JSR-03) since access modifiers are  
> > > > > bypassed
> > > > > currently.
> > > > > *    Classes and Methods are public by default.
> > > > > *    Class variables are package (default) by default.
> > > > >
> > > > > 1) Please confirm that the current JSR-03 implementation is correct  
> > > > > for
> > > > > Classes and Methods.
> > > > > 2) Should class variables be package access since this doesn't  
> > > > > exist in
> > > > > Groovy (AFAIK)?
> > > >
> > > > My belief is that the current implementation is correct. I don't  
> > > > remember methods ever defaulting to private so I think the first  
> > > > entry is just an error.
> > > >
> > > > I think that class variables should be public just like methods and  
> > > > property get/set functions.
> > > >
> > > > I notice that @Property p results in p having package access - I  
> > > > would have expected it to be private (or, possibly, protected)
> > > >
> > > > Package access is pretty useless in Groovy. As all the acess goes  
> > > > through the MetaClass or a helper class called from the MetaClass  
> > > > then there is no real use for package access.
> > > >
Reply | Threaded
Open this post in threaded view
|

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

tugwilson

On 2 Nov 2005, at 01:15, [hidden email] wrote:

> Here is another example given by Antti Karanta at Sep 12.
>
> X---------------------------------------
> public class CloneExample {
>
>   public static void main(String[] args) {
>     Object o = new Object();
>     Object o2 = o.clone();
>   }
>
> }
> X---------------------------------------
>
> The result is:
> Caught: java.lang.CloneNotSupportedException: java.lang.Object
>         at CloneExample.main(CloneExample.groovy:5)
>
>
> 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.


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
In reply to this post by phkim
On Wed, Nov 02, 2005 at 12:02:41AM +0900, [hidden email] wrote:

> On Tue, Nov 01, 2005 at 11:53:44PM +0900, [hidden email] wrote:
> > On Tue, Nov 01, 2005 at 10:46:27PM +0900, [hidden email] wrote:
> > > On Mon, Oct 24, 2005 at 10:21:24PM -0500, LARSON, BRIAN (SBCSI) wrote:
> > > > I found a JIRA issue for this:
> > > > http://jira.codehaus.org/browse/GROOVY-923
> > > > It points to another inconsistency at:
> > > > http://groovy.codehaus.org/Migration+From+Classic+to+JSR+syntax
> > > > Which says:
> > > > The default access level for members of Groovy classes has changed from
> > > > "public" to "protected".
> > > >
> > > > Also, http://groovy.codehaus.org/jsr/spec/Chapter06Names.html says:
> > > > The default access is that a member can be accessed anywhere within the
> > > > package that contains its declaration...
> > > >
> > > >
> > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > *protected in Groovy is the equivalent of both package-protected and
> > > > protected in Java. i.e. you can have friends in the same package - or
> > > > derived classes can also see protected members.
> > > >
> > > > A protected field in Groovy results in a protected access modifier in
> > > > the resulting class.
> > > >
> > > > I tested with the current CVS HEAD and it is the same as JSR-03.
> > > >
> > > > I think class variables should probably be protected or public.  The
> > > > above comment about protected = package + protected is not consistent
> > > > with the implementation and other statements.
> > > >
> > > > If this has been decided, please let me know and I'll correct all these
> > > > conflicting statements and the 923 issue.
> > >
> > > As I know, every access privilege is public in the current Groovy.
> > > That is, private/protected/public/package has no meaning.
> > > Everything is public.
> > >
> > > The current Groovy does not support the encapsulation.
> >
> > Here is an exmple:
> >
> > def x = 3
> > println x     // Good here.
> > binding.@variables = null
> > println x     // What happens here?
> >
> >
> > Kim
> >
>
> Here is another example:
>
> def x = 1..3
> println x                // Good here.  Print out 1..3
> x.each { println it }    // Works fine. Print out 1, 2, and 3
> x.@from = 10
> println x                // Print out 10..3
> x.each { println it }    // Print nothing
>
>
> Kim


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?


def fn2(String s) {
   s.@value = ['b', 'a', 'r'] as char[]
}

def y = "foo"
println y    // Print out foo.

fn2(y)
println y    // Print out bar.  Is String immutable or not?


def fn3(Collection k) {
   k.@c = [100, 300, 500]
}

def z = [1, 2, 3].asImmutable()
println z    // Print out foo.

fn3(z)
println z    // Print out bar.  Is z immutable or not?
X-----------------------------------------------

Are Integer, String, Immtable List immutable in Groovy?

Kim

>
> > > So Groovy is not an OOP language.
> > >
> > > Here is an sentence from Groovy Home which explains what is Groovy language:
> > >
> > >       Groovy is an agile dynamic language for the Java 2 Platform that
> > >       has many of the features that people like so much
> > >       in languages like Python, Ruby and Smalltalk,
> > >       making them available to Java developers using a Java-like syntax.
> > >
> > >
> > > AFAIK, you should change something there.
> > >
> > >
> > > Kim
> > >
> > > >
> > > > Brian Larson
> > > > SBC
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: John Wilson [mailto:[hidden email]]
> > > > Sent: Monday, October 24, 2005 4:35 AM
> > > > To: [hidden email]
> > > > Subject: Re: [groovy-dev] Default access for methods in Groovy
> > > >
> > > > On 24 Oct 2005, at 06:11, LARSON, BRIAN (SBCSI) wrote:
> > > > > I'm doing a presentation for work on Groovy and I ran across two pages
> > > > > which
> > > > > conflict concerning the default access for methods in Groovy.
> > > > >
> > > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > >  *methods are private by default and classes public
> > > > > http://groovy.codehaus.org/Scripts+and+Classes says:
> > > > >  One difference with Groovy is that by default things are public  
> > > > > unless
> > > > > you specify otherwise.
> > > > >
> > > > > I tested it to be sure (with JSR-03) since access modifiers are  
> > > > > bypassed
> > > > > currently.
> > > > > *    Classes and Methods are public by default.
> > > > > *    Class variables are package (default) by default.
> > > > >
> > > > > 1) Please confirm that the current JSR-03 implementation is correct  
> > > > > for
> > > > > Classes and Methods.
> > > > > 2) Should class variables be package access since this doesn't  
> > > > > exist in
> > > > > Groovy (AFAIK)?
> > > >
> > > > My belief is that the current implementation is correct. I don't  
> > > > remember methods ever defaulting to private so I think the first  
> > > > entry is just an error.
> > > >
> > > > I think that class variables should be public just like methods and  
> > > > property get/set functions.
> > > >
> > > > I notice that @Property p results in p having package access - I  
> > > > would have expected it to be private (or, possibly, protected)
> > > >
> > > > Package access is pretty useless in Groovy. As all the acess goes  
> > > > through the MetaClass or a helper class called from the MetaClass  
> > > > then there is no real use for package access.
> > > >
Reply | Threaded
Open this post in threaded view
|

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

phkim
On Wed, Nov 02, 2005 at 04:26:04PM +0900, [hidden email] wrote:

> On Wed, Nov 02, 2005 at 12:02:41AM +0900, [hidden email] wrote:
> > On Tue, Nov 01, 2005 at 11:53:44PM +0900, [hidden email] wrote:
> > > On Tue, Nov 01, 2005 at 10:46:27PM +0900, [hidden email] wrote:
> > > > On Mon, Oct 24, 2005 at 10:21:24PM -0500, LARSON, BRIAN (SBCSI) wrote:
> > > > > I found a JIRA issue for this:
> > > > > http://jira.codehaus.org/browse/GROOVY-923
> > > > > It points to another inconsistency at:
> > > > > http://groovy.codehaus.org/Migration+From+Classic+to+JSR+syntax
> > > > > Which says:
> > > > > The default access level for members of Groovy classes has changed from
> > > > > "public" to "protected".
> > > > >
> > > > > Also, http://groovy.codehaus.org/jsr/spec/Chapter06Names.html says:
> > > > > The default access is that a member can be accessed anywhere within the
> > > > > package that contains its declaration...
> > > > >
> > > > >
> > > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > > *protected in Groovy is the equivalent of both package-protected and
> > > > > protected in Java. i.e. you can have friends in the same package - or
> > > > > derived classes can also see protected members.
> > > > >
> > > > > A protected field in Groovy results in a protected access modifier in
> > > > > the resulting class.
> > > > >
> > > > > I tested with the current CVS HEAD and it is the same as JSR-03.
> > > > >
> > > > > I think class variables should probably be protected or public.  The
> > > > > above comment about protected = package + protected is not consistent
> > > > > with the implementation and other statements.
> > > > >
> > > > > If this has been decided, please let me know and I'll correct all these
> > > > > conflicting statements and the 923 issue.
> > > >
> > > > As I know, every access privilege is public in the current Groovy.
> > > > That is, private/protected/public/package has no meaning.
> > > > Everything is public.
> > > >
> > > > The current Groovy does not support the encapsulation.
> > >
> > > Here is an exmple:
> > >
> > > def x = 3
> > > println x     // Good here.
> > > binding.@variables = null
> > > println x     // What happens here?
> > >
> > >
> > > Kim
> > >
> >
> > Here is another example:
> >
> > def x = 1..3
> > println x                // Good here.  Print out 1..3
> > x.each { println it }    // Works fine. Print out 1, 2, and 3
> > x.@from = 10
> > println x                // Print out 10..3
> > x.each { println it }    // Print nothing
> >
> >
> > Kim
>
>
> 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?
>
>
> def fn2(String s) {
>    s.@value = ['b', 'a', 'r'] as char[]
> }
>
> def y = "foo"
> println y    // Print out foo.
>
> fn2(y)
> println y    // Print out bar.  Is String immutable or not?
>
>
> def fn3(Collection k) {
>    k.@c = [100, 300, 500]
> }
>
> def z = [1, 2, 3].asImmutable()
> println z    // Print out foo.
>
> fn3(z)
> println z    // Print out bar.  Is z immutable or not?
> X-----------------------------------------------
>
> Are Integer, String, Immtable List immutable in Groovy?
>
> Kim
>


Sorry again (revised comment):
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?


def fn2(String s) {
   s.@value = ['b', 'a', 'r'] as char[]
}

def y = "foo"
println y    // Print out foo.

fn2(y)
println y    // Print out bar.  Is String immutable or not?


def fn3(Collection k) {
   k.@c = [100, 300, 500]
}

def z = [1, 2, 3].asImmutable()
println z    // Print out [1, 2, 3].

fn3(z)
println z    // [100, 300, 500].  Is z immutable or not?
X---------------------------------------

Are the immmutable objects (Integer, String, Immutable Collection)
immutable in Groovy?


Kim

> >
> > > > So Groovy is not an OOP language.
> > > >
> > > > Here is an sentence from Groovy Home which explains what is Groovy language:
> > > >
> > > >       Groovy is an agile dynamic language for the Java 2 Platform that
> > > >       has many of the features that people like so much
> > > >       in languages like Python, Ruby and Smalltalk,
> > > >       making them available to Java developers using a Java-like syntax.
> > > >
> > > >
> > > > AFAIK, you should change something there.
> > > >
> > > >
> > > > Kim
> > > >
> > > > >
> > > > > Brian Larson
> > > > > SBC
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: John Wilson [mailto:[hidden email]]
> > > > > Sent: Monday, October 24, 2005 4:35 AM
> > > > > To: [hidden email]
> > > > > Subject: Re: [groovy-dev] Default access for methods in Groovy
> > > > >
> > > > > On 24 Oct 2005, at 06:11, LARSON, BRIAN (SBCSI) wrote:
> > > > > > I'm doing a presentation for work on Groovy and I ran across two pages
> > > > > > which
> > > > > > conflict concerning the default access for methods in Groovy.
> > > > > >
> > > > > > http://groovy.codehaus.org/Differences+from+Java says:
> > > > > >  *methods are private by default and classes public
> > > > > > http://groovy.codehaus.org/Scripts+and+Classes says:
> > > > > >  One difference with Groovy is that by default things are public  
> > > > > > unless
> > > > > > you specify otherwise.
> > > > > >
> > > > > > I tested it to be sure (with JSR-03) since access modifiers are  
> > > > > > bypassed
> > > > > > currently.
> > > > > > *    Classes and Methods are public by default.
> > > > > > *    Class variables are package (default) by default.
> > > > > >
> > > > > > 1) Please confirm that the current JSR-03 implementation is correct  
> > > > > > for
> > > > > > Classes and Methods.
> > > > > > 2) Should class variables be package access since this doesn't  
> > > > > > exist in
> > > > > > Groovy (AFAIK)?
> > > > >
> > > > > My belief is that the current implementation is correct. I don't  
> > > > > remember methods ever defaulting to private so I think the first  
> > > > > entry is just an error.
> > > > >
> > > > > I think that class variables should be public just like methods and  
> > > > > property get/set functions.
> > > > >
> > > > > I notice that @Property p results in p having package access - I  
> > > > > would have expected it to be private (or, possibly, protected)
> > > > >
> > > > > Package access is pretty useless in Groovy. As all the acess goes  
> > > > > through the MetaClass or a helper class called from the MetaClass  
> > > > > then there is no real use for package access.
> > > > >
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:08:20AM +0000, John Wilson wrote:

>
> On 2 Nov 2005, at 01:15, [hidden email] wrote:
>
> >Here is another example given by Antti Karanta at Sep 12.
> >
> >X---------------------------------------
> >public class CloneExample {
> >
> >  public static void main(String[] args) {
> >    Object o = new Object();
> >    Object o2 = o.clone();
> >  }
> >
> >}
> >X---------------------------------------
> >
> >The result is:
> >Caught: java.lang.CloneNotSupportedException: java.lang.Object
> >        at CloneExample.main(CloneExample.groovy:5)
> >
> >
> >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.

Kim

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