Re: Code classes

0 views
Skip to first unread message

Ingo Blechschmidt

unread,
May 2, 2005, 12:22:03 PM5/2/05
to perl6-l...@perl.org
Hi,

Thomas Sandlaß wrote:
> the main reason for this mail: aliasing $_ in methods to the first
> invocant would badly mix these two concepts!

I think so, too.

I'd like to see:
$.foo # attribute of $?SELF
@.foo # ditto
%.foo # ditto
&.foo # method of $?SELF
.foo # method of $?SELF
$_.foo # method of $_

This means that we've to write two additional letters in given {} and
map {} and somesuch...
@foo.map:{ $_.method > 42 }
given $foo { $_.foo(42); $_.bar(23) }
...but it also means that
* "." as secondary sigil ($.foo, @.foo, %.foo, &.foo) is
consistent (always refers to $?SELF), and
* you don't have to use $self in methods again only because
you are (implicitly or explicitly) binding $_ to something
else.

IMHO, this advantages are worth the two extra chars.


--Ingo

--
Linux, the choice of a GNU | When cryptography is outlawed, bayl bhgynjf
generation on a dual AMD | jvyy unir cevinpl!
Athlon! |

Thomas Sandlaß

unread,
May 2, 2005, 12:02:24 PM5/2/05
to p6l
HaloO,

I don't know if this is usefull and if it is were this information
should be put. I've reworked the Code class chart from A06 to look
as follows:

invocant(s) : Code
_________ ____:__ ___|___
| | : | |
SubMethod Method : Sub Block
___| : |___
| | : | |
Rule | : | Macro
|____:__|
| :
MultiMethod :

role Code {...}

role Return {...}
role Dispatch[ ::How ] {...}

class Block does Code
class Sub does Code & Return {...}
class SubMethod does Code & Return & Dispatch of Class {...}
class Method does Code & Return & Dispatch of Object {...}
class Macro is Sub {...}
class Rule is Method {...}
class MultiMethod is Method & Sub does Dispatch of List
of Object {...}


The vertical line of colons divides the methods from the subs basically.
This mirrors the declaration syntax of the invocants which are left of
the colon in a signature. The three underscore variables $_, @_ and %_
are right of the colon in my understanding and this is the main reason


for this mail: aliasing $_ in methods to the first invocant would badly
mix these two concepts!

Comments?
--
TSa (Thomas Sandlaß)


Wolverian

unread,
May 2, 2005, 4:29:49 PM5/2/05
to perl6-l...@perl.org
On Mon, May 02, 2005 at 06:22:03PM +0200, Ingo Blechschmidt wrote:
> &.foo # method of $?SELF
> .foo # method of $?SELF
> $_.foo # method of $_

We could also define them as:

&.foo # method on $?SELF
.foo # method on $_
$_.foo # method on $_

The .foo syntax is very special, after all, so you can't really be
consistent with it. I prefer it be the topic, in any case.

--
wolverian

signature.asc

Larry Wall

unread,
May 2, 2005, 8:42:47 PM5/2/05
to perl6-l...@perl.org
On Mon, May 02, 2005 at 11:29:49PM +0300, wolverian wrote:

We're still discussing it on @Larry, but I think we can make that work.
There are some ambiguities with &.foo that depend on the declaration
of it, but those can probably be resolved based on that declaration.
This proposal is also consistent with the first invocant setting the
topic, so "when" still works inside a method. So paint me back into
the ".foo == $_.foo" camp this week, and now the ".foo == $self.foo"
camp can start carping again. :-)

By the way, this probably goes along with a policy of allowing
$.foo, @.foo, and %.foo outside of the class as well. These would
not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute).
It seems to me that this would facilitate cut and paste of code,
as well as the possibility of moving the attribute declaration to
or from parent classes transparently. (To give credit where it's
due, this was inspired by someone's misreading of S12 on PerlMonks
a month or so ago.) Since the compiler is figuring out whether
$.foo means an attribute or a method call on your behalf, to force
a virtual call in the class itself, you'd have to say $self.foo(),
which seems like a decent safety feature to me, insofar as it makes
it harder to accidentally call yourself in an infinite regress.
Which probably means that (just like $.foo) the &.foo is devirtualized
in any class that defines method foo, or we're back to the too-easy
infinite regress.

I think it probably works...

Larry

Larry Wall

unread,
May 3, 2005, 3:33:45 AM5/3/05
to perl6-l...@perl.org
On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote:
: We're still discussing it on @Larry, but I think we can make that work.

Well, now I think &.foo() won't work, since &.foo should be reserved
for a sub ref attribute to be consistent. But I think all we have
to do is find some other character to use for self calls instead of '&'.
There are a number of candidates, and I can convince myself that there
are good arguments for most of them, so now I just have to pick the one
with the weakest arguments against it. :-)

Larry

Thomas Sandlaß

unread,
May 3, 2005, 3:52:00 AM5/3/05
to perl6-l...@perl.org
Larry Wall wrote:
> On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote:
> : We're still discussing it on @Larry, but I think we can make that work.

Sorry if I don't know, but where or what is @Larry?
I guess some IRC?


> Well, now I think &.foo() won't work, since &.foo should be reserved
> for a sub ref attribute to be consistent. But I think all we have
> to do is find some other character to use for self calls instead of '&'.
> There are a number of candidates, and I can convince myself that there
> are good arguments for most of them, so now I just have to pick the one
> with the weakest arguments against it. :-)

I'm not carping about the syntax but about the in my eyes unfortunate
binding of the topic variable to one of the invocants. My chart should
give the idea of the split between these two "worlds". The invocants
are OOish or typeish while the parameters are procedural.
Has that binding been re-painted as well?

BTW, what does $.foo outside of class scope mean? $.foo == $_.foo?
How are parameters passed? $.foo( $arg, "blahh" )?
--
TSa (Thomas Sandlaß)

Luke Palmer

unread,
May 3, 2005, 3:04:06 AM5/3/05
to Thomas Sandlaß, perl6-l...@perl.org
Thomas Sandlaß writes:
> Larry Wall wrote:
> >On Mon, May 02, 2005 at 05:42:47PM -0700, Larry Wall wrote:
> >: We're still discussing it on @Larry, but I think we can make that work.
>
> Sorry if I don't know, but where or what is @Larry?

Ahh, you came in too late. I don't remember who coined it, but @Larry
is the array of Larrys, that is, the design team.

> I guess some IRC?

No #Larry {yet, >:-}.

> >Well, now I think &.foo() won't work, since &.foo should be reserved
> >for a sub ref attribute to be consistent. But I think all we have
> >to do is find some other character to use for self calls instead of '&'.
> >There are a number of candidates, and I can convince myself that there
> >are good arguments for most of them, so now I just have to pick the one
> >with the weakest arguments against it. :-)
>
> I'm not carping about the syntax but about the in my eyes unfortunate
> binding of the topic variable to one of the invocants.

I agree with you there. $Larry has said that he wants `when` to work
at the top level in methods, which is the main reasoning for the topic
binding. Indeed, that might cause people to use .method to mean "call
on self", and then get shot in the foot when they reorganize things, but
I think it would be easy enough just to teach them not to. If they do,
then they're the ones with the gun.

> BTW, what does $.foo outside of class scope mean?

It means:

BEGIN { die "Can't use \$.foo outside of class scope"; }

:-)

Luke

Thomas Sandlaß

unread,
May 3, 2005, 5:33:51 AM5/3/05
to perl6-l...@perl.org
Luke Palmer wrote:
> Ahh, you came in too late. I don't remember who coined it, but @Larry
> is the array of Larrys, that is, the design team.

Aha. What does **@Larry evaluate to? How do the elements of
@Larry communicate?


> I agree with you there. $Larry has said that he wants `when` to work
> at the top level in methods, which is the main reasoning for the topic
> binding. Indeed, that might cause people to use .method to mean "call
> on self", and then get shot in the foot when they reorganize things, but
> I think it would be easy enough just to teach them not to. If they do,
> then they're the ones with the gun.

If 'when' were the single exception then setting $_ = $?SELF (note: copy
not binding) there when in method code should be doable for the compiler.


>>BTW, what does $.foo outside of class scope mean?
>
>
> It means:
>
> BEGIN { die "Can't use \$.foo outside of class scope"; }

That contradicts $Larry's statement: "By the way, this probably goes along


with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well.
These would not refer to the actual attribute, but would call $self.foo()
underneath (except in the class that actually defines the attribute)."

OK, he has got a 'probably' there. Would it be the one character saver
$.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
of derived (or even unrelated?) classes and direct access to the instance
variable in the class scope that has the corresponding 'has $.foo' declaration?

Regards,
--
TSa (Thomas Sandlaß)

Aaron Sherman

unread,
May 3, 2005, 7:59:19 AM5/3/05
to Thomas Sandlaß, Perl6 Language List
On Tue, 2005-05-03 at 05:33, Thomas Sandlaß wrote:
> Luke Palmer wrote:

> >>BTW, what does $.foo outside of class scope mean?

> > It means:

> > BEGIN { die "Can't use \$.foo outside of class scope"; }
>
> That contradicts $Larry's statement: "By the way, this probably goes along
> with a policy of allowing $.foo, @.foo, and %.foo outside of the class as well.
> These would not refer to the actual attribute, but would call $self.foo()
> underneath (except in the class that actually defines the attribute)."
>
> OK, he has got a 'probably' there. Would it be the one character saver
> $.foo == $_.foo outside class scope, $.foo == $?SELF.foo in methods
> of derived (or even unrelated?) classes and direct access to the instance
> variable in the class scope that has the corresponding 'has $.foo' declaration?

If it's ever $_, then you have the problem where the code:

given $someobj {
when $.foo {...}
}

gets wrapped in a method later in the project:

class X {
method y {
given $someobj {
when $.foo {...}
}
}
}

Now you have two options: either it's ALWAYS $?SELF.foo because it's
inside a method (and thus, this code is now wrong), or it's only
$?SELF.foo if X or any ancestor has a $.foo, otherwise it's $_.foo.

I like the idea that $.foo ALWAYS means the $.foo in the current class.
Anything else gets very ugly later on.


On a side note about auto-accessors, if I say:

class X {
has $.foo;
}
class Y is X {
has %.foo;
}

What happens to the accessors for X.foo?

If there's no current plan, my suggestion would be that every
auto-accessor has an alias of the form "TYPE_NAME". That is, these hold
true:

has $foo; # Gets .Any_foo
has int $foo; # Gets .int_foo
has @foo; # Gets .Array_foo
has @foo is MyArray; # Gets .MyArray_foo
has $foo does X; # Hmmm... probably just .Any_foo

These should be automatically overridden by explicit method declarations
in this OR an ancestor class (to avoid mysterious bugs when you forget
that your "$.foo" is going to override your Any_foo method that has
nothing to do with an accessor), but should override inherited
auto-accessors... which of course means having to keep track of why a
method was created in the metaclass, but I don't think that's too hard.

--
Aaron Sherman <a...@ajs.com>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback


Larry Wall

unread,
May 3, 2005, 8:36:04 AM5/3/05
to Perl6 Language List
On Tue, May 03, 2005 at 08:29:22AM -0400, Aaron Sherman wrote:
: On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
: > On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
:
: > : On a side note about auto-accessors, if I say:

: > :
: > : class X {
: > : has $.foo;
: > : }
: > : class Y is X {
: > : has %.foo;
: > : }
: > :
: > : What happens to the accessors for X.foo?
: >
: > Overridden just like any such method.
:
: Are has declarations ordered as they appear?
:
: That is, does:
:
: has $.foo;
: has %.foo;
:
: give me an accessor for %.foo or for whatever one happened to be
: declared last?

Neither--I'd think that'd be a fatal compile-time error.

: NOTE: Either way, I think the above should at least issue a warning that
: you're overriding the definition of the auto-accessor declared within
: the same class definition, and the same should probably happen with
: composition sources (though not inheritance). This is implied in S12
: when it says that roles auto-detect conflicting methods, but should
: explicitly refer to attributes as well.

Probably.

Larry

Aaron Sherman

unread,
May 3, 2005, 8:29:22 AM5/3/05
to Larry Wall, Perl6 Language List
On Tue, 2005-05-03 at 08:07, Larry Wall wrote:
> On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:

> : On a side note about auto-accessors, if I say:


> :
> : class X {
> : has $.foo;
> : }
> : class Y is X {
> : has %.foo;
> : }
> :
> : What happens to the accessors for X.foo?
>

> Overridden just like any such method.

Are has declarations ordered as they appear?

That is, does:

has $.foo;
has %.foo;

give me an accessor for %.foo or for whatever one happened to be
declared last?

NOTE: Either way, I think the above should at least issue a warning that


you're overriding the definition of the auto-accessor declared within
the same class definition, and the same should probably happen with
composition sources (though not inheritance). This is implied in S12
when it says that roles auto-detect conflicting methods, but should
explicitly refer to attributes as well.

--

Larry Wall

unread,
May 3, 2005, 8:07:40 AM5/3/05
to Perl6 Language List
On Tue, May 03, 2005 at 07:59:19AM -0400, Aaron Sherman wrote:
: I like the idea that $.foo ALWAYS means the $.foo in the current class.

: Anything else gets very ugly later on.

Well, since I'm not going with & for "self", I'm probably not going with
the $.foo meaning anything outside of the class either.

: On a side note about auto-accessors, if I say:


:
: class X {
: has $.foo;
: }
: class Y is X {
: has %.foo;
: }
:
: What happens to the accessors for X.foo?

Overridden just like any such method.

Larry

Larry Wall

unread,
May 3, 2005, 12:24:03 PM5/3/05
to perl6-l...@perl.org
On Tue, May 03, 2005 at 09:00:49AM -0700, David Wheeler wrote:
: On May 3, 2005, at 00:04 , Luke Palmer wrote:
:
: >I agree with you there. $Larry has said that he wants `when` to work
:
: Shouldn't that be @Larry[0]?

That depends on whether you think the rest of them are pushy or shiftless. :-)

Larry

Reply all
Reply to author
Forward
0 new messages