Re: [groovy-dev] Default access for methods in Groovy
On Tue, Nov 01, 2005 at 11:53:44PM +0900, phkim@... wrote:
> On Tue, Nov 01, 2005 at 10:46:27PM +0900, phkim@... 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. <at> 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. <at> 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:tug@...]
> > > Sent: Monday, October 24, 2005 4:35 AM
> > > To: dev@...
> > > 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 <at> 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.
> > >
RSS Feed