./method

1 view
Skip to first unread message

Juerd

unread,
May 15, 2005, 7:44:44 AM5/15/05
to perl6-l...@perl.org
A few days ago, when typing ./pugs,... You can guess the rest :)

I suggest

./method

to mean $?SELF.method, and

../method

to mean $?SELF.SUPER::method, or however that's normally written.

This syntax doesn't clash with anything, doesn't introduce whitespace
asymmetry and doesn't require anything other than ASCII.

If you go back to what inspired it, the mnemonic becomes clear: unix
filesystems. However, it's far fetched and none of the people I've asked
think it's a good one. Still, it works for me and may even work in
textbooks.

The best thing about this new proposal is that everyone so far agrees
that it's feasible, easy to write and not ugly.

(Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
"+" and "=" be thought of as meta-operators to ".", and from now on, to
"./" and "../" as well, so you get "./+method". This isn't as complex as
it looks right now.)

Your opinions please! (I ask those who already responded off-list, to
repeat their opinion here)


Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html

Autrijus Tang

unread,
May 15, 2005, 8:16:49 AM5/15/05
to Juerd, perl6-l...@perl.org
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> I suggest
> ./method
> to mean $?SELF.method
>
> Your opinions please! (I ask those who already responded off-list, to
> repeat their opinion here)

I like it. Tentatively implemented as r3253 for people to experiment
with. The converted examples/games/wizard.p6 looks good; the relevant
snippet is paraphrased below:

class Person is Mortal {
has Weapon %.weapons;
...
method battle_choice (Monster $enemy) {
given prompt("Your choice?") {
when %.weapons {
./attack($enemy, $.weapons{$_});
}
}
...
}
}

Thanks,
/Autrijus/

Yuval Kogman

unread,
May 15, 2005, 8:53:26 AM5/15/05
to Juerd, perl6-l...@perl.org
On Sun, May 15, 2005 at 13:44:44 +0200, Juerd wrote:
> A few days ago, when typing ./pugs,... You can guess the rest :)
>
> I suggest
>
> ./method
>
> to mean $?SELF.method, and
>
> ../method

> Your opinions please! (I ask those who already responded off-list, to
> repeat their opinion here)

Wonderful!

--
() Yuval Kogman <nothi...@woobling.org> 0xEBD27418 perl hacker &
/\ kung foo master: /me whallops greyface with a fnord: neeyah!!!!!!!

Fagyal Csongor

unread,
May 15, 2005, 9:13:17 AM5/15/05
to Yuval Kogman, Juerd, perl6-l...@perl.org
I also like this notation.

However, as a side note, let me voice the opinion that the "bad
reputation" of Perl partially comes from the fact that it often looks
like line noise. I think everybody know this. Now there has been a lot
of discussion on finding different meanings for any two-character
combinations of ^/$.[]+-@%&~{}\ (I am sorry to say it that way). As a
Perl programmer I like this, but I am afraid that other programmers of
different languages ("...who will burn in Hell..." :-)), or newcommers
to Perl6 will have trouble even to pick up the basics. But again, this
is just a side note.

In this particular case, I like ./method because I don't like
$?SELF.method, which looks like my terminal is in UTF-8 and there is an
ISO-8859-2 character between $ and SELF :-))

- Cs.

Abhijit Mahabal

unread,
May 15, 2005, 10:10:56 AM5/15/05
to Juerd, perl6-l...@perl.org

> (Note that "./" and "../" are prefix operators, and unlike ".?", ".*",
> ".+" and ".=", cannot be used infix. In fact, it requires that "?", "*",
> "+" and "=" be thought of as meta-operators to ".", and from now on, to
> "./" and "../" as well, so you get "./+method". This isn't as complex as
> it looks right now.)
>
> Your opinions please! (I ask those who already responded off-list, to
> repeat their opinion here)

Since new syntax is being suggested for these things, here is my
suggestion, very late in the discussion, but here it is anyway.

$_ is the topic; the "only" problem is that we have two topics here: an
immediate and a "main" topic. What if a method call binds the invocant to
*both* $_ and the "bigger topic" $__?

method foo($x){
# invocant accessible by both $__ and $_
for (1..3) {
# invocant accessible by $__ only
.bar(); # called on $_
$__.bat(); # called on the invocant
$?CLASS.bas();
}
}

I like this because things still look a little like a topic. This is not
better than $o/$O, except that $__ looks more like $_ (but maybe it looks
too much like $_, and that alone could invalidate this proposal).

Comments?

--abhijit

Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/

Juerd

unread,
May 15, 2005, 10:25:16 AM5/15/05
to Abhijit Mahabal, perl6-l...@perl.org
Abhijit Mahabal skribis 2005-05-15 9:10 (-0500):

> $_ is the topic; the "only" problem is that we have two topics here: an
> immediate and a "main" topic. What if a method call binds the invocant to
> *both* $_ and the "bigger topic" $__?
> (...)

> I like this because things still look a little like a topic. This is not
> better than $o/$O, except that $__ looks more like $_ (but maybe it looks
> too much like $_, and that alone could invalidate this proposal).

I do think $__ looks too much like $_. A bit better would be to not have
a "bigger" topic, but a "higher" topic, $-, but the problem with seeing
the invocant as a topic on another level, is that
inconsistency/asymmetry would be introduced between

method {
# topic is object
given 5 {
# topic is 5
# "bigger" topic is object, we access it as $__
}
}

and

given $object {
# topic is object
given 5 {
# topic is 5
# $object is neither $_ nor $__
}
}

For this reason, I think an alias for $?SELF should not visually
resemble $_.

I don't think an alias for $?SELF is needed, because the only thing you
usually do with it, is call to call a method. In the rare occasion that
you want to pass it around, $?SELF or explicitly signatured $self
suffices (and is the clearest way to write it IMO).

You didn't say what you think about ./method; What is your opinion?

Abhijit Mahabal

unread,
May 15, 2005, 10:38:16 AM5/15/05
to Juerd, perl6-l...@perl.org
On Sun, 15 May 2005, Juerd wrote:

> I do think $__ looks too much like $_.

Yeah, lets drop that idea.

> A bit better would be to not have
> a "bigger" topic, but a "higher" topic, $-, but the problem with seeing
> the invocant as a topic on another level, is that
> inconsistency/asymmetry would be introduced between
>
> method {
> # topic is object
> given 5 {
> # topic is 5
> # "bigger" topic is object, we access it as $__
> }
> }
>
> and
>
> given $object {
> # topic is object
> given 5 {
> # topic is 5
> # $object is neither $_ nor $__
> }
> }

By "bigger topic" I did not mean "outer topic"; I was thinking that $__
can *only* get bound to an invocant.


> You didn't say what you think about ./method; What is your opinion?

I like it. ( I assume you mean:
.method is always $_.method
./method is always $?SELF.method )
Yes, I like it a lot!

Adam Kennedy

unread,
May 15, 2005, 8:25:23 AM5/15/05
to perl6-l...@perl.org
Juerd wrote:
> A few days ago, when typing ./pugs,... You can guess the rest :)
>
> I suggest
>
> ./method
>
> to mean $?SELF.method, and
>
> ../method
>
> to mean $?SELF.SUPER::method, or however that's normally written.

I'm opinionless on the latter, since in my opinion cross-calling
supermethods (calling a supermethod other than the one you are currently
in) has been nothing but bad in my experience.

But it's definitely the best suggestion so far for implicit invocant method.

If this was apache.org, I'd +1 it happily.

Looking at various keyboard layouts however, the nordics among us (who
have / at shift-7) are probably not going to like it though :)

But US/UK/CJK are all to the right of the period, so it's a very
friendly combination in that regard.

Adam K

Adam

Juerd

unread,
May 15, 2005, 10:40:04 AM5/15/05
to Larry Wall, perl6-l...@perl.org
Larry Wall skribis 2005-05-15 7:32 (-0700):
> (such as that it makes it too easy to use SUPER semantics rather than
> NEXT semantics)

I'm not intimately familiar with the advantages and disadvantages SUPER
versus NEXT, but they may both be dangerous if used on a *different*
method.

Because of that, it is probably better to go with ./method not have
../method, and use just "super;" and "next METHOD;" (I don't like the
latter, for its METHOD", so hereby I'm suggesting "supermeth" and
"nextmeth", and that we make "method { }" "meth { }", as "subroutine" is
shortened to "sub". Or maybe I'm just going crazy now.).

Larry Wall

unread,
May 15, 2005, 10:32:04 AM5/15/05
to perl6-l...@perl.org
On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
: A few days ago, when typing ./pugs,... You can guess the rest :)

:
: I suggest
:
: ./method
:
: to mean $?SELF.method, and
:
: ../method
:
: to mean $?SELF.SUPER::method, or however that's normally written.

That's almost terminally cute, but I like it. Unless someone can
think of a major objection (such as that it makes it too easy to use
SUPER semantics rather than NEXT semantics), let's go with it.

From a programmer point of view the mnemonic is pragmatically good,
because use of ./ in shell is mostly only for commands, so people
are used to seeing it as part of an invocation process, not just a
file location process.

Larry

Fagyal Csongor

unread,
May 15, 2005, 10:23:26 AM5/15/05
to Abhijit Mahabal, Juerd, perl6-l...@perl.org
Abhijit Mahabal wrote:

Yep. I'd hate it to move the cursor every time on __ to see if it is _
or __. I have bad eyes and a small monitor :-)

This view won't be popular, but I'd prefer all these "built-ins" look
like $_SOMETHING, like
$_, $_SELF, $_CLASS and so on... even $_ to be an alias to $_TOPIC .

- Fagzal

Autrijus Tang

unread,
May 15, 2005, 11:16:38 AM5/15/05
to Juerd, Larry Wall, perl6-l...@perl.org
On Sun, May 15, 2005 at 04:40:04PM +0200, Juerd wrote:
> Because of that, it is probably better to go with ./method not have ../method

Good. I was having a headache trying to convince myself ../method
was a good idea, but can't. Thanks for delivering me. :)

/Autrijus/

Matt Diephouse

unread,
May 15, 2005, 12:22:07 PM5/15/05
to perl6-l...@perl.org
Larry Wall <la...@wall.org> wrote:
> On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> : A few days ago, when typing ./pugs,... You can guess the rest :)
> :
> : I suggest
> :
> : ./method
> :
> : to mean $?SELF.method, and
> :
> : ../method
> :
> : to mean $?SELF.SUPER::method, or however that's normally written.
>
> That's almost terminally cute, but I like it. Unless someone can
> think of a major objection (such as that it makes it too easy to use
> SUPER semantics rather than NEXT semantics), let's go with it.

Does this mean private methods will be called like this?

./:method()

FWIW, I like the original spec best. I'm not sure that the problems
with it aren't being exaggerated. But I've not written much Perl 6 yet
either...

--
matt diephouse
http://matt.diephouse.com

Larry Wall

unread,
May 15, 2005, 12:24:35 PM5/15/05
to perl6-l...@perl.org
On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
: Does this mean private methods will be called like this?
:
: ./:method()

No, I think that's still just

.:method()

Larry

Juerd

unread,
May 15, 2005, 12:34:47 PM5/15/05
to perl6-l...@perl.org
Larry Wall skribis 2005-05-15 9:24 (-0700):

Both, depending on what you're calling it on.

./:method # $?SELF.:method
.:method # $_.:method

The : is part of the method name.

I've been looking for a good moment to come with this, but there is
none, making this as good a point as any: I don't like the dot in
attributes, and the colon that replaces it.

If we have .method and .:method, then we should have $.attr and $.:attr.

Not $:attr.

Juerd

unread,
May 15, 2005, 1:18:21 PM5/15/05
to Aaron Sherman, Juerd, Perl6 Language List
Now:
Declaration Explicit Implicit $_ $?SELF
has $.var | $obj.var \ .var \ ./var \
has $:var | $obj.:var \ .:var \ ./:var \

Consistent:
has $.var \ $obj.var \ .var \ ./var \
has $.:var \ $obj.:var \ .:var \ ./:var \

See it yet? It's about consistency in the whole scheme, not the clarity
of a single element.

(I wouldn't mind if $:var was a shortcut syntax for $.:var, although we
will regret this when we think of an even better purpose for the colon
as a sigil.)

Note that it's not *implicit* $?SELF. "./" is a prefix operator that
calls a method on $?SELF, not an infix operator that when prefixly used
defaults to something. "./" is not like ".+" and friends. It cannot be
used infix, it does not default to anything. Read the two characters as
one.

Aaron Sherman

unread,
May 15, 2005, 1:10:18 PM5/15/05
to Juerd, Perl6 Language List
On Sun, 2005-05-15 at 18:34 +0200, Juerd wrote:

> I've been looking for a good moment to come with this, but there is
> none, making this as good a point as any: I don't like the dot in
> attributes, and the colon that replaces it.
>
> If we have .method and .:method, then we should have $.attr and $.:attr.

Let's have a look, side-by-side:

Old way:

Declaration Explicit Implicit $_ Implicit $?SELF

has $.var $obj.var .var ./var
has $:var $obj.:var .:var ./:var

Your proposal:

has $.var $obj.var .var ./var
has $.:var $obj.:var .:var ./:var

Scanning over those two sets visually, I just don't see that extra "."
as a very big win.... Perhaps if I try in some code:

$.:var = 1;

vs

$:var = 1;

Still not seeing it....


Ashley Winters

unread,
May 15, 2005, 6:45:45 PM5/15/05
to perl6-l...@perl.org
On 5/15/05, Autrijus Tang <autr...@autrijus.org> wrote:
> On Sun, May 15, 2005 at 01:44:44PM +0200, Juerd wrote:
> > I suggest
> > ./method
> > to mean $?SELF.method

Sounds good.

> class Person is Mortal {
> has Weapon %.weapons;
> ...
> method battle_choice (Monster $enemy) {
> given prompt("Your choice?") {
> when %.weapons {
> ./attack($enemy, $.weapons{$_});
> }
> }

Looks good, too. It's convenient enough to encourage me to use it
consistently. Even when $_ points at the invocant, I'd be strongly
inclined to use ./method for $self.method. After a decade of using
unix shells, typing ./ is closer to huffman(1.1) than huffman(2).

This is a really clean solution.

Ashley Winters :vote<yea>

Rob Kinyon

unread,
May 15, 2005, 8:30:06 PM5/15/05
to Juerd, Brad Bowman, perl6language
On 5/15/05, Juerd <ju...@convolution.nl> wrote:
> Brad Bowman skribis 2005-05-16 9:56 (+1000):
> > Would it conflict with range + pattern? Or has that changed anyway?
>
> No, "./" and "../" are prefix only, so they cannot clash with an infix
> operator like "..".

How would

print "Foo" while $self../method;

parse? What does the parser do when it sees "../"? I know what it will
do when it sees that ../method terminates the condition. But, will it
backtrack?

Rob

Juerd

unread,
May 15, 2005, 8:25:43 PM5/15/05
to Brad Bowman, perl6language
Brad Bowman skribis 2005-05-16 9:56 (+1000):
> Would it conflict with range + pattern? Or has that changed anyway?

No, "./" and "../" are prefix only, so they cannot clash with an infix
operator like "..".

Damian Conway

unread,
May 15, 2005, 8:33:19 PM5/15/05
to perl6-l...@perl.org
Larry Wall wrote:

This missing design rationale here is that the colon acts as part of the unary
operator:

./ unary public-method-call-on-invocant

.: unary private-method-call-on-invocant

So the rule is:

One-character operator --> call on $_
Two-character operator --> call on $?SELF"

Damian

Larry Wall

unread,
May 15, 2005, 8:51:02 PM5/15/05
to perl6language

../ would only be recognized where a term is expected, so that would
parse as well (or as poorly) as:

print "Foo" while $self .. /method;

Larry

Matt Diephouse

unread,
May 15, 2005, 8:54:52 PM5/15/05
to Damian Conway, perl6-l...@perl.org
Damian Conway <dam...@conway.org> wrote:
> Larry Wall wrote:
>
> > On Sun, May 15, 2005 at 12:22:07PM -0400, Matt Diephouse wrote:
> > : Does this mean private methods will be called like this?
> > :
> > : ./:method()
> >
> > No, I think that's still just
> >
> > .:method()
>
> This missing design rationale here is that the colon acts as part of the unary
> operator:
>
> ./ unary public-method-call-on-invocant
>
> .: unary private-method-call-on-invocant

This introduces some asymmetry with accessors, which are currently
$.attr and $:attr. I think in this case it's more consistent to use
the $/attr for public attributes. Unfortunately, I find that rather
ugly, which is why I gave up trying to find a secondary sigil for
public methods called on the invocant in the first place.

In other words, I don't see any solution here that is less than ideal.

Any thoughts?

Larry Wall

unread,
May 15, 2005, 8:55:59 PM5/15/05
to perl6-l...@perl.org
On Sun, May 15, 2005 at 06:34:47PM +0200, Juerd wrote:
: .:method # $_.:method

It is almost certainly the case that you can't call a private method
of $_ unless it just happens to have trusted you, and since it's
such an unusual thing, calling into another class's private method
should have an explicit invocant in any case. So it's fine by me
for that notation to always mean $self.:method, following Damian's
one-character vs two-character generalization. The problem with
being consistent is that there are lots of ways to be consistent,
and they're all inconsistent with each other.

Larry

Larry Wall

unread,
May 15, 2005, 9:01:21 PM5/15/05
to perl6-l...@perl.org

I think almost all internal access to one's own attributes will be
via $.foo and $:bar. Outside the class there is already a complete
asymmetry between public and private methods, so there's no reason to
invent a perfect encoding for the few cases where it matters. $.foo is
good enough to indicate that there are probably external methods,
and $:bar is good enough to indicate that there probably aren't.

Larry

Juerd

unread,
May 16, 2005, 5:45:05 AM5/16/05
to Damian Conway, perl6-l...@perl.org
Damian Conway skribis 2005-05-16 10:33 (+1000):

> This missing design rationale here is that the colon acts as part of the
> unary operator:
> ./ unary public-method-call-on-invocant
> .: unary private-method-call-on-invocant
> So the rule is:
> One-character operator --> call on $_
> Two-character operator --> call on $?SELF"

I was very specific about ./ being prefix only. Aligning it with .: is
ugly, because .: can be used infix.

$object.method
$object.:method

given $object {
.method
.:method # !!
}

Either it should do the expected thing, default to $_, or one of .:'s
syntaxes must be made invalid. Don't try to convince me that prefix .:
is an entirely different operator, because it is spelled the same and
does the same thing (call a private method). The only thing that's
different is that its invocant is left out of the code, and when we then
use something that isn't there, we call that a default. And defaults are
always $_, never $?SELF. But that you know.

Anything that begins with a dot looks way too much like the lone dot to
subtly mean something else.

Either infix .: must go away, or prefix .: must operate on $_.

I think infix .: can go, because calling private methods should be
harder anyway. Make that $object.!!(:)method for all I care.

And I think "method :name" must be very differently spelled, because it
looks like : is part of the name, which makes me want consistency:

$o.private $.private .private ./private
$o.:private $.:private .:private ./:private

Even forcing whitespace between : and name would already solve this:
"method : name". It's ugly though.

To be honest, the current fog around private methods, and my not liking
much of the way they work, is pushing me towards good old _private
instead, ignoring the whole wildly special cased colon method thingies.

Aaron Sherman

unread,
May 16, 2005, 5:54:08 AM5/16/05
to Juerd, Perl6 Language List
On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> Now:
> Declaration Explicit Implicit $_ $?SELF
> has $.var | $obj.var \ .var \ ./var \
> has $:var | $obj.:var \ .:var \ ./:var \
>
> Consistent:
> has $.var \ $obj.var \ .var \ ./var \
> has $.:var \ $obj.:var \ .:var \ ./:var \
>
> See it yet? It's about consistency in the whole scheme, not the clarity
> of a single element.

I'm not sure I see that you changed anything other than changing "Old
way" to "Now", "Your proposal" to "Consistent", adding separator
characters between the columns, and removing the word "Implicit" from
the last column.

I'm still not seeing the problem. Counting down and then right, I read
those: "$." means attribute; "$:" means private attribute; "$x." means
accessor method; "$x.:" means private accessor method; and so on...

I think you're confusing the method glyph "." and the attribute glyph,
also "." in the first and second columns. Consistency would be to make
accessor methods use both the attribute and accessor glyphs "..", but
that would cause at least 4 problems that I can think of, so "." is a
nice simple thing to do. In the case of private accessor methods, most
of those reasons go away, so ".:" needn't be (and in fact can't be)
shortened.

All of the details aside, I simply don't see newbies getting all that
confused. For starters, there's no particular reason that they would
have to use private attributes all that often, and if they did, they
don't really EVER have to use accessor methods on them, though style
might nudge them in that direction, there's no real impact on
scalability the way there is with regular accessors (because every use
of the private accessor is local to the class definition).

Now, the one place I can see that you should ALWAYS use the private
attribute accessors is in roles. Here, it would be essential, as you
don't know what the composing class might want to do to that method, so
the only place that I see this being a big concern is in roles that have
private attributes. Certainly an edge case newbies won't contend with
all that often, yes?

> Note that it's not *implicit* $?SELF. "./" is a prefix operator that
> calls a method on $?SELF

That's picking nits. I know that, but was referring to the implicit use
of $?SELF regardless of the syntax one would have to employ in order to
use it explicitly.


Juerd

unread,
May 16, 2005, 6:23:05 AM5/16/05
to Aaron Sherman, Perl6 Language List
Aaron Sherman skribis 2005-05-16 5:54 (-0400):

> On Sun, 2005-05-15 at 19:18 +0200, Juerd wrote:
> > Now:
> > Declaration Explicit Implicit $_ $?SELF
> > has $.var | $obj.var \ .var \ ./var \
> > has $:var | $obj.:var \ .:var \ ./:var \
> > Consistent:
> > has $.var \ $obj.var \ .var \ ./var \
> > has $.:var \ $obj.:var \ .:var \ ./:var \
> > See it yet? It's about consistency in the whole scheme, not the clarity
> > of a single element.
> I'm not sure I see that you changed anything other than changing "Old
> way" to "Now", "Your proposal" to "Consistent", adding separator
> characters between the columns, and removing the word "Implicit" from
> the last column.

Okay, let's try it differently, then:

Now:
Declaration Explicit Implicit $_ $?SELF

. | . \ . \ . \
: | .: \ .: \ . : \

Consistent:
. \ . \ . \ . \
.: \ .: \ .: \ . : \


> I think you're confusing the method glyph "." and the attribute glyph,
> also "." in the first and second columns.

It's the same thing. $.foo installs an accessor *method*. $object.foo
calls that method, it doesn't access $object's $.foo directly.

> > Note that it's not *implicit* $?SELF. "./" is a prefix operator that
> > calls a method on $?SELF
> That's picking nits.

In the process of designing something, every single nit must be picked.
Don't take it personally.

Aaron Sherman

unread,
May 16, 2005, 9:08:34 AM5/16/05
to Juerd, Perl6 Language List
On Mon, 2005-05-16 at 12:23 +0200, Juerd wrote:
> Aaron Sherman skribis 2005-05-16 5:54 (-0400):

> > I'm not sure I see that you changed anything
[...]

> Okay, let's try it differently, then:

[...something that looks like braille...]

And now, you've s/[\$\w]+//g; what point are you making, Juerd? I think
I've demonstrated that I get it. I just don't agree with your thesis
that that one character is a) a problem or b) inconsistent.

> > I think you're confusing the method glyph "." and the attribute glyph,
> > also "." in the first and second columns.
>
> It's the same thing.

Well, there's the problem. If you see those as the same symbol, then of
course this is deeply confusing. After all, "$.foo" doesn't behave
anything like a method, and yet it uses the method symbol.

Try looking at those two symbols as TWO SYMBOLS, and I think your life
gets easier.

"$.foo" -- Attribute glyph "." used after scalar variable glyph "$".
"$obj.foo" -- Method glyph "." used after scalar variable.

If you de-couple those in your mind, then there's

> $.foo installs an accessor *method*.

Well, it can. It won't if there's already a method there, of course, and
that's an important distinction. There's no fundamental tie between the
two. The auto-accessor is just a convenience that is placed there for
you if you didn't go out of your way to supply one. It's not "part of"
the attribute, and so we should not name the attribute in order to match
the naming of the method. If anything, we should do the reverse, but I'm
happy with the way it is.

> $object.foo calls that method, it doesn't access $object's $.foo
> directly.

Yes, that's correct. That's because you're using the method-invocation
glyph. If you had used the attribute glyph ("$.foo"), then you would get
direct access. Are you telling me this because you didn't think I knew?
It certainly doesn't seem to further the point....

> > > Note that it's not *implicit* $?SELF. "./" is a prefix operator that
> > > calls a method on $?SELF

> > That's picking nits.
>
> In the process of designing something, every single nit must be picked.
> Don't take it personally.

You removed the context supplied by my next sentence. Your nit to which
I was referring was NOT a design comment, and I still hold that my
original usage of "implicit" is correct.


Aaron Sherman

unread,
May 16, 2005, 10:07:02 AM5/16/05
to Juerd, Perl6 Language List
On Mon, 2005-05-16 at 09:08, Aaron Sherman wrote:

> Well, there's the problem. If you see those as the same symbol, then of
> course this is deeply confusing.

I just want to make the point that the "you" in that sentence is "you,
the user of Perl", not "you, Juerd". Obviously, you are not confused
here, you just have an opinion that differs from mine. Please don't take
my comments as condescending (especially the ones I type first thing in
the morning ;-)

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


Carl Franks

unread,
May 19, 2005, 11:50:01 AM5/19/05
to perl6-language
On 5/19/05, Martin Kuehl <martin...@gmail.com> wrote:

> I have tried, but I can't make myself like it.

<aol>I'm afraid I have to agree.</aol>
When I saw it used in code after this discussion (I think it must have
been somewhere in pugs t/ or ext/) my reaction was "yuck".

(for what it's worth)

Carl

Reply all
Reply to author
Forward
0 new messages