Newsgroups: perl.perl6.language
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!nntp.perl.org
Return-Path: <austin_hasti...@yahoo.com>
Mailing-List: contact perl6-language-h...@perl.org; run by ezmlm
Delivered-To: mailing list perl6-langu...@perl.org
Delivered-To: perl6-langu...@perl.org
Message-ID: <20030409145623.2535.qmail@web12308.mail.yahoo.com>
Date: Wed, 9 Apr 2003 07:56:23 -0700 (PDT)
Reply-To: Austin_Hasti...@yahoo.com
Subject: Re: Properties & Methods
To: Luke Palmer <fibon...@babylonia.flatirons.org>, Austin_Hasti...@yahoo.com
Cc: Austin_Hasti...@Yahoo.com, perl6-langu...@perl.org
In-Reply-To: <ygck7e3ybkx.fsf@babylonia.flatirons.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SMTPD: qpsmtpd/0.25, http://develooper.com/code/qpsmtpd/
X-Spam-Check-By: one.develooper.com
X-Spam-Status: No, hits=-0.5 required=7.0 tests=CARRIAGE_RETURNS,IN_REP_TO,QUOTED_EMAIL_TEXT,SPAM_PHRASE_00_01 version=2.44
X-SMTPD: qpsmtpd/0.25, http://develooper.com/code/qpsmtpd/
Approved: n...@nntp.perl.org
From: austin_hasti...@yahoo.com (Austin Hastings)
References: <ygck7e3ybkx.fsf@babylonia.flatirons.org>
Lines: 87


--- Luke Palmer <fibon...@babylonia.flatirons.org> wrote:
> > Urk!
> > 
> > So we're doing object access, but the namesearch looks like:
> > 
> > $root.visited -> in lexical scope as property? 
> >               -> in object property namespace? (see next; order?)
> >               -> in object method list?        (see prev; order?)
> >               -> in class method list?  (??)
> >               -> in multi namespace?
> >               -> in package sub namespace?
> >               -> in global sub namespace?
> >
> > 
> > Right?
> 
> No.  One more time:
> 
>     my $visited = new Property;
>     #                              v
>     die "Already visited" if $root.$visited;
>     #                              ^
> 

Argh. This is what I get for corresponding before the sun crosses the
yardarm. You're right. That'll work, and it doesn't have anything to do
with lexical scope. I could just as well create a new property at the
package level, or class level, and hang it on there. 

Which is nice, because it effectively gives us a "namespace" constraint
for properties.

Going one step farther, this is probably the way all properties should
be handled by default: assume that any property I<not already declared>
exists at the "basic outer scope" of the using code. (Class, or
Package, by default.)

That means that when my code says:

sub do_stuff($x) {
  $x but= fnord;
}

and some other 6PAN code  says:

package other;

sub other_sub($x) {
  show $fear if $x.fnord;
}

the default P6 behavior will be to interfere with each other.

But if we use $fnord, things work out:

$fnord = new Property;
sub do_stuff($x) {
  $x but= $fnord;
}
======
package other;
our $fnord = new Property;
sub other_sub($x) {
  show fear if $x.$fnord;
}

(The properties that SHOULD be global can be defined globally. The
properties that want to be added as global can be defined that way. But
the default behavior for properties should be scoped, to avoid
interference.)

> See that $ after the . ?  It's like a dynamic method call, except it
> knows it's looking for a property because $visited is a property
> object, instead of a method object.  It has just as many problems
> with closures as dynamic method calls do: none.
> 
> Oh, and named methods come before named properties in the lookup
> list.
> And, in light of this explanation, the "lexical scope as property"
> shouldn't be there.

Yes.

=Austin