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 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.
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 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

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

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

Martin C. Martin
In reply to this post by phkim
The message you quote was part of a long thread on exactly these issues, and blackdrag has been doing a lot of work on this.

I know we can't implement Java's system in Groovy, but was a consensus reached on an alternative?  What's the current plan/status of this?

- Martin

[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.
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 [[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 Tue, Nov 01, 2005 at 10:05:15AM -0500, Martin C. Martin wrote:
> The message you quote was part of a long thread on exactly these issues,
> and blackdrag has been doing a lot of work on this.

No, it is not blackdrag, it is me.
blackdrag proposed me to do that.
And I did as his proposal.

>
> I know we can't implement Java's system in Groovy, but was a consensus
> reached on an alternative?  What's the current plan/status of this?

I have implemented the feature of private/public/protected already
and committed it.
But soon John Wilson reverted the commit.

Kim

>
> - Martin
>
> [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.
> >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
In reply to this post by Martin C. Martin

On 1 Nov 2005, at 15:05, Martin C. Martin wrote:

> The message you quote was part of a long thread on exactly these  
> issues, and blackdrag has been doing a lot of work on this.
>
> I know we can't implement Java's system in Groovy, but was a  
> consensus reached on an alternative?  What's the current plan/
> status of this?


I don't think that there is a consensus yet but I can give you some  
facts about public vs protected in Groovy:

1/ We access all protected and public members of a class via the  
MetaClass (something of an oversimplification here there are nastily  
little issues like calling a method via super for which we have not  
yet found a good solution). As the MetaClass is not a subclass of the  
class it's a MetaClass of we can't generate bytecodes to access the  
member. We have to use reflection and the setAccessible() call. This  
has a significant impact on performance: calling a protected method  
seems to take between 100 and 500 times linger than calling a public  
method.

2/ As the MetaClass can't tell anything about the class that called  
it then all Groovy code can access both public and protected members  
of both Groovy and Java classes.

3/ How we access private members is also not yet resolved but this  
will probably be done by adopting a subset of the Java rules and  
generating inline bytecodes (i.e. not going via the MetaClass). The  
special properties of private members makes this feasible. We do not  
have the same flexibility with protected members (things like  
DefaultGroovyMethods mandate the use of the MetaClass).


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 05:32:25PM +0000, John Wilson wrote:

>
> On 1 Nov 2005, at 15:05, Martin C. Martin wrote:
>
> >The message you quote was part of a long thread on exactly these  
> >issues, and blackdrag has been doing a lot of work on this.
> >
> >I know we can't implement Java's system in Groovy, but was a  
> >consensus reached on an alternative?  What's the current plan/
> >status of this?
>
>
> I don't think that there is a consensus yet but I can give you some  
> facts about public vs protected in Groovy:
>
> 1/ We access all protected and public members of a class via the  
> MetaClass (something of an oversimplification here there are nastily  
> little issues like calling a method via super for which we have not  
> yet found a good solution). As the MetaClass is not a subclass of the  
> class it's a MetaClass of we can't generate bytecodes to access the  
> member. We have to use reflection and the setAccessible() call. This  
> has a significant impact on performance: calling a protected method  
> seems to take between 100 and 500 times linger than calling a public  
> method.
>
> 2/ As the MetaClass can't tell anything about the class that called  
> it then all Groovy code can access both public and protected members  
> of both Groovy and Java classes.
>
> 3/ How we access private members is also not yet resolved but this  
> will probably be done by adopting a subset of the Java rules and  
> generating inline bytecodes (i.e. not going via the MetaClass). The  
> special properties of private members makes this feasible. We do not  
> have the same flexibility with protected members (things like  
> DefaultGroovyMethods mandate the use of the MetaClass).
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

How about generators?

Kim

Reply | Threaded
Open this post in threaded view
|

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

tugwilson

On 1 Nov 2005, at 17:39, [hidden email] wrote:

>
> How about generators?

Err yes.... what about generators?


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 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?
>
>
> John Wilson
> The Wilson Partnership
> http://www.wilson.co.uk
>
>

How does the private/public/protect access work about generators?

Kim

Reply | Threaded
Open this post in threaded view
|

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

tugwilson

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


12345