On Sat, 12 Oct 2002, Me wrote:
: I've looked before for discussion of the rationale behind
: introducing attr/has and failed to find it. I noticed you
: mention Zurich, so perhaps this decision followed from
: discussion in living color (as against b+w).
: 
: Anyhow, what was deemed wrong with using my/our?

Nothing the matter with "our" for class attributes since they're
already stored in the package if we follow Perl 5's lead.  But using
"my" for instance attributes is problematic if we allow a class to
be reopened:

    class Blurfl {
        my $.foo;
    }
    ...
    class Blurfl is continued {
        print $.foo;
    }

This violates the Perl 6 rule that "my" is always limited to a block.
That's why we came up with "attr", which has since mutated to "has".

: And...
: 
: > class Zap {
: > my %.zap_cache; # a private classwide attribute
: > our $.zap_count = 0; # a public classwide attribute
: >
: > has $.foo;
: > has $.bar;
: > }
: >
: > It may be that $.zap_count is public not so much because of the class
: definition
: > where it would default to private, but because $.zap_count's real
: global name is
: > $Zap::.zap_count.  To get a public accessor method you might still
: need to declare
: > it public.  And you could get a public accessor method to the "my"
: variable as well
: > the same way.
: 
: So:
: 
: class Zap {
:   my %zap_cache;                 # var, lexical
:   my %.zap_cache;                # class attr, lexical
:   my %.zap_cache is public;      # class attr, lexical/public
:   our $zap_count = 0;            # var, lexical/global
:   our $.zap_count = 0;           # class attr, lexical/global
:   our $.zap_count = 0 is public; # class attr, lexical/public/global
:   has $.foo;                     # instance attr, lexical
:   has $.bar is public;           # instance attr, lexical/public
: }
: 
: Yes?

No "yes" till Apo 12.  :-)

And probably not "yes" then.  These are all provisional notions.
Note that "attr" only lasted a month...but then, I said when I made
it up in Zurich that it was a placeholder because I couldn't think of
anything better.  And the whole public/private thing is a placeholder
for whatever we eventually come up with to deal with access control.
We're just as likely to end up with "is rw" or some such, especially
if we decide to allow you to declare attributes that are readable
but not writeable through the class interface.

: What about something like:
: 
:   my  $.foo;           # private instance attr
:   our $.foo;           # public  instance attr
: 
:   my  $foo;            # as p5
:   our $foo;            # as p5
: 
:   MY  $.foo;           # private class attr
:   OUR $.foo;           # public class attr
: 
:   MY  $foo;            # invalid?
:   OUR $foo;            # invalid?
: 
:       method bar;      # public  instance method
:   my  method bar;      # private instance method
:   our method bar;      # public  instance method
:   MY  method bar;      # private class    method
:   OUR method bar;      # public  class    method

Doesn't do much for me.  I think it's a mistake to overload my/our with
private/public distinctions because we might also want to distinguish
read/write.  More subtly, it changes the "me" of my/our to mean the
current object or class rather than the current lexical scope, which
is going to be intrinsically confusing.

Plus it's not clear that class attributes are worth SHOUTING over.

It's my gut feeling that class variables are already pretty close to
"our" variables, so we only need a new word for instance variables,
which have a very different scope from any variables in Perl 5.
Plus I like emphasizing the has/is distinction to help keep people
from using inheritance when they should be using composition.

At least, that's what I like this week...

Larry

Reply via email to