Re: ^method ?
Rod Adams skribis 2005-05-14 20:09 (-0500): > >>o. > >>O. > >>this. > >>self. > >>me. > >Not special syntax, meaning you can no longer use these identifiers for > >your own class. Bad style to use single-letter identifiers, but we know > >what trouble $a and $b in Perl 5 cause, and the B:: namespace. > I believe they could all be implemented as a global function that > returns $CALLER::?SELF, or however you spell that. They can, but that does not free up the identifiers for user definition. I wonder how CALLER::'s $?SELF is written too :) > >>° (an idea I just had. would likely need a 7-bit option as well) > >Not on any of the keyboards that I regularly use, and the > >ascii-equivalent would be \w, which has the problems described above. > Neither is ¥ (except in Japan, but I don't think that was a deciding > factor), which has a 7-bit version that isn't even infix. However, it is > in the extended ASCII table, same as « » ¥. so the 7-bit version could > just be $?SELF, and act as an encouragement for people to get better > editors. With the Windows US-International keyboard layout, it's > AltGr-Shift-; Other systems should have standard ways to type it as well. Yen has an ascii equivalent that is \w, but that doesn't clash with identifiers because Y is an infix operator. Terms are not expected there. There is no "extended" or "8-bit" ASCII. ASCII is 7 bits by definition and has 128 characters. The character set you're using is called iso-8859-1, also known as latin-1. I don't buy the "encouragement to get better editors" thing. Using digraphs in the editor is extremely poor huffmanization, even though the end result is short. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
Rob Kinyon skribis 2005-05-14 21:12 (-0400): > What's wrong with just defaulting to $self? Are you kidding, trolling or just completely ignorant of what has been discussed the past days? > That's standard P5 OO, expected everywhere No, Perl 5 has no default for methods. Its -> always needs an LHS. Or was your choice of words poor, and did you not mean to discuss the dot's *default*, but instead a standard way to write the current invocant? Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote: > Or was your choice of words poor, and did you not mean to discuss the > dot's *default*, but instead a standard way to write the current > invocant? I think what Rob suggested is that: method ($foo) means method ($self: $foo) by default, but you can still override it with the invocant name of your choice. Thanks, /Autrijus/ pgpicCyVKk9Ry.pgp Description: PGP signature
./method
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
Re: ^method ?
Autrijus Tang skribis 2005-05-15 19:28 (+0800): > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote: > > Or was your choice of words poor, and did you not mean to discuss the > > dot's *default*, but instead a standard way to write the current > > invocant? > I think what Rob suggested is that: > method ($foo) > means > method ($self: $foo) Then I hereby apologise to Rob for my own poor choice of words. I don't like the idea of having a normal identifier ever used by default, except $_, which is already aliased to the invocant. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ./method
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/
pgpNNHVNEvjPo.pgp
Description: PGP signature
Re: ./method
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 <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me whallops greyface with a fnord: neeyah!!! pgpEXOgsYEirP.pgp Description: PGP signature
Re: ./method
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 ^/[EMAIL PROTECTED]&~{}\ (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.
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!
Re: ./method
(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/
Re: ^method ?
For starters, about the only combination harder to hit with on spanned hand might be ctrl-F5. I've remapped my keyboard so that I push shift for numbers and leave it off for the various symbols on the top row. ^ isn't hard to type for me. (Plus, is it that hard to use two hands with shifted keys like you were taught in typing class?) Can I assume that there is agreement already that in order to sit a beginner down and have them learn and write basic Perl, they shouldn't have to: 1) Remap their keyboard 2) Use characters that aren't on most keyboards I have horrible visions of newbie Win32 coders getting frustrated when the only way they can see to do something is to open up the Windows Character Map program and copy/paste from there. The current situation of the << and >> characters seems fine in this regard, because it's not something you are going to need to use until you get more advanced. Having the... Start->Programs->Accessories->SystemTools->CharacterMap,Click,"Select","Copy",Close,Ctrl-V ... º character as the default invocant method (to use that option as an example) is something I'd much like to avoid. Adam K
Re: ./method
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
Re: ./method
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?
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method
Abhijit Mahabal wrote:
(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).
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
Re: ./method
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
Re: ./method
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!
--abhijit
Abhijit Mahabal http://www.cs.indiana.edu/~amahabal/
Re: ./method
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.).
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
http://convolution.nl/gajigu_juerd_n.html
Re: ./method
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/ pgpPIwCGEgfd1.pgp Description: PGP signature
Re: ^method ?
On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > > Or was your choice of words poor, and did you not mean to discuss the
> > > dot's *default*, but instead a standard way to write the current
> > > invocant?
> > I think what Rob suggested is that:
> > method ($foo)
> > means
> > method ($self: $foo)
>
> Then I hereby apologise to Rob for my own poor choice of words.
>
> I don't like the idea of having a normal identifier ever used by
> default, except $_, which is already aliased to the invocant.
Autrijus is much more eloquent that (apparently) I can ever hope to
be. Thank you.
If I understand correctly, we're discussing what should happen if you
do something like .method($foo) within another method and if there
should be shorthand way of writing whatever it is.
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int foo ) {
$self.otherMethod( foo );
}
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
JS as part of my argument.)
If you have
method ( Int foo ) {
.otherMethod( foo );
}
That would be
method ( Int foo ) {
$_.otherMethod( foo );
}
Just like expected.
Rob
Re: ./method
Larry Wall <[EMAIL PROTECTED]> 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
Re: ./method
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
Re: ./method
Larry Wall skribis 2005-05-15 9:24 (-0700): > 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() 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 -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
S29 Q: Rules for boxed types
In reviewing S29 as it stands now, I see that many builtins both receive
and return boxed basic types. This seems like potentially spurious
overhead in some situations, while essential in others, so I wanted to
work out a set of rules for when boxed vs. unboxed types would be used
in core routines (given that all rules will have exceptions).
Here's my first pass for review, using the standard meaning of "must"
and "should" from the RFC world.
* By default, basic type parameters should be unboxed
* "is rw" parameters must be boxed
* Return values should not be boxed by default
This means:
sub lc(str ?$string = $CALLER::_) returns str {...}
sub chomp(Str ?$string is rw = $CALLER::_) returns int {...}
This all assumes that it is far more trivial to extract an unboxed basic
type from a boxed basic type (which requires accessing encapsulated
data) than it is to go the other way (which requries construction).
Thoughts?
$:attr vs $.:attr
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 ExplicitImplicit $_ 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
Re: $:attr vs $.:attr
Now: Declaration ExplicitImplicit $_ $?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. Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: S29 Q: Rules for boxed types
Aaron Sherman wrote: In reviewing S29 as it stands now, I see that many builtins both receive and return boxed basic types. This seems like potentially spurious overhead in some situations, while essential in others, so I wanted to work out a set of rules for when boxed vs. unboxed types would be used in core routines (given that all rules will have exceptions). My thoughts on writing it were: The boxed version is the specification, in that the language must support them. Think about using a SubType somewhere, and you see why. However, I also fully expected implementations to add an easy optimization of including unboxed equivalents and letting MMD sort it out. -- Rod Adams
Re: junctions vs English negatives.
On 5/14/05, Damian Conway <[EMAIL PROTECTED]> wrote:
> Larry wrote:
>
> > I don't think we can allow this situation to stand. Either we have
> > to make != and !~ and ne transform themselves via "not raising", or
> > we have to disallow negative comparisons on junctions entirely.
> >
> > Opinions?
>
> Making them DWIM here would be a mistake, since the dwimmery would disappear
> if anyone refactored:
>
> if $note != $do | $re | $me {...}
>
> to the supposedly identical:
>
> if $note != $do || $note != $re || $note != $me {...}
>
> That would be a bad outcome...pedagogically as well as from a maintainability
> point-of-view.
Hmm. I'll just that if != is implemented like this:
multi sub infix: (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
Luke
Re: ./method
On 5/15/05, Autrijus Tang <[EMAIL PROTECTED]> 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
Re: junctions vs English negatives.
On 5/15/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> multi sub infix: (Any|Junction $a, Any|Junction $b) {
> !($a == $b);
> }
>
> Then it Just Works.
Also, that's the right way to provide a working != for any object
which defines ==. We all want that, right?
Ashley Winters
Re: ./method
> : ../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. Would it conflict with range + pattern? Or has that changed anyway? perl -nle 'print if (1../pattern./)' This isn't an objection, just a query. Brad -- That one's own district is unsophisticated and unpolished is a great treasure. Imitating another style is simply a sham. -- Hagakure http://bereft.net/hagakure/
Re: ^method ?
On 15/05/05 11:17 -0400, Rob Kinyon wrote:
> On 5/15/05, Juerd <[EMAIL PROTECTED]> wrote:
> > Autrijus Tang skribis 2005-05-15 19:28 (+0800):
> > > On Sun, May 15, 2005 at 01:19:53PM +0200, Juerd wrote:
> > > > Or was your choice of words poor, and did you not mean to discuss the
> > > > dot's *default*, but instead a standard way to write the current
> > > > invocant?
> > > I think what Rob suggested is that:
> > > method ($foo)
> > > means
> > > method ($self: $foo)
> >
> > Then I hereby apologise to Rob for my own poor choice of words.
> >
> > I don't like the idea of having a normal identifier ever used by
> > default, except $_, which is already aliased to the invocant.
>
> Autrijus is much more eloquent that (apparently) I can ever hope to
> be. Thank you.
>
> If I understand correctly, we're discussing what should happen if you
> do something like .method($foo) within another method and if there
> should be shorthand way of writing whatever it is.
>
> Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
> we should use $self wherever $?SELF would be used. $_ is still the
> topic and would be the default invocant if you have .method($foo).
> What I'm saying is that you can have
>
> method ( Int foo ) {
> $self.otherMethod( foo );
> }
+1
FWIW, after reading this whole conundrum, I think that erring on the
side of pragmatism seems like the right choice. If I jump into some
source code and see:
$self.some_such();
I am going to feel right at home. No doubt about it.
As to *how* it works (by hook, crook, preclaration or macro etc), I
leave it to Larry to do the proper hand waving to make it fit in cleanly
(for some Wallian definition of clean).
Cheers, Brian
> and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
> JS as part of my argument.)
>
> If you have
> method ( Int foo ) {
> .otherMethod( foo );
> }
>
> That would be
> method ( Int foo ) {
> $_.otherMethod( foo );
> }
>
> Just like expected.
>
> Rob
Re: ^method ?
.
On 15 May 2005, at 16:17, Rob Kinyon wrote:
Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
we should use $self wherever $?SELF would be used. $_ is still the
topic and would be the default invocant if you have .method($foo).
What I'm saying is that you can have
method ( Int foo ) {
$self.otherMethod( foo );
}
and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
JS as part of my argument.)
If you have
method ( Int foo ) {
.otherMethod( foo );
}
That would be
method ( Int foo ) {
$_.otherMethod( foo );
}
Just like expected.
My ill-considered and probably not very understandable thoughts:
- As has been said with great eloquence earlier, virtually everywhere
in Perl 6 so far when you leave something out the default is taken to
be $_
- As has also been said, elsewhere, internal consistency is a great
feature of a language people are trying to learn
Given these two points, in my mind anything other than making
.method($foo);
mean
$_.method($foo);
is utterly absurd. If it means $_.method($foo) outside a method
definition and $?SELF.method($foo) inside one then I think it's a
reasonable expectation for people learning Perl 6 to throw up their
hands and start complaining loudly (and possibly going back to their
previous language of choice).
It also seems to make sense to me that the invocant of a method is
the default topic for the method body - that is, after all, what that
code has been invoked in order to do something to/with. Is it really
a serious hardship to do what you have to do everywhere else in Perl
6 if you want to preserve the topic, and give it a name of your own
choosing?
method m($self: $foo) {
$self.do_something();
}
is hardly difficult to deal with in my opinion. Neither is
method m($foo) {
my $self := $_;
$self.do_something();
}
for that matter. Remembering not to clobber the topic when you want
to keep it will be second-nature to Perl 6 people very shortly after
they start, I'm sure, as it's always seemed to me that it's going to
use a lot more things which allow you to do a lot of topic
manipulation instead of having to think up silly variable names all
the time (given {} will be particularly handy for my code, thank you
very much for that!) Thus I don't think that given {} and other such
things inside the method body are going to be something people will
particularly find problematic with regard to clobbering their
invocant, as there is an easy and clear syntactic way to give it an
alias, and normal variable binding can rescue it at any point up to
the point where you assign something else to $_ (assuming I've
understood binding correctly, of course). And indeed afterwards, if
you use $?SELF. Which, to be honest, I'm not particularly keen on in
terms of appearance or ease of typing, but I don't think we're going
to need it except in 'emergencies' - $_ and the invocant naming
syntax will provide plenty of opportunity for people to refer to $?
SELF by a saner and more appropriate name for their given situation.
In the long run I can see making sure .method() defaults to $_
everywhere will save me a fair bit of typing - my methods (in C++ and
in Perl 5) are usually made up either of coordinating calls to other
methods of the same object, which will be nice and simple due to
being able to omit the $_ or $?SELF or other name I might have given
the invocant; or made up of a bunch of operations largely concerning
other objects, in which case the whole thing goes out of the window
because you're barely talking to the invocant at all. In that case,
changing the topic at various points is probably going to be an
advantage, depending on the code structure of course.
That may lead to the potential issue of calling the same thing by two
different names ($_ and $?SELF or $self or $this or $me or whatever)
in the same method, but that's more a question of style than anything
else - the careful programmer will make sure it's understandable
what's going on, while the careless programmer will make a mess no
matter what the language lets them do.
So that's what I think anyway. Not that anybody should listen to me
of course, but I really can't see the logic in some of the
suggestions being thrown about here, so I thought it was prudent to
try and head them off before my favourite unfinished language gets
spoiled.
Re: ./method
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 "..". Juerd -- http://convolution.nl/maak_juerd_blij.html http://convolution.nl/make_juerd_happy.html http://convolution.nl/gajigu_juerd_n.html
Re: ^method ?
On 15/05/05 22:48 +0100, Matthew Walton wrote:
> .
>
> On 15 May 2005, at 16:17, Rob Kinyon wrote:
> >Right now, P6 has $?SELF and I'm saying that instead of using $?SELF,
> >we should use $self wherever $?SELF would be used. $_ is still the
> >topic and would be the default invocant if you have .method($foo).
> >What I'm saying is that you can have
> >
> >method ( Int foo ) {
> >$self.otherMethod( foo );
> >}
> >
> >and it will DWIM. Just like Java, C++, and Javascript. (Yes, I'm using
> >JS as part of my argument.)
> >
> >If you have
> >method ( Int foo ) {
> >.otherMethod( foo );
> >}
> >
> >That would be
> >method ( Int foo ) {
> >$_.otherMethod( foo );
> >}
> >
> >Just like expected.
>
> My ill-considered and probably not very understandable thoughts:
>
> - As has been said with great eloquence earlier, virtually everywhere
> in Perl 6 so far when you leave something out the default is taken to
> be $_
> - As has also been said, elsewhere, internal consistency is a great
> feature of a language people are trying to learn
>
> Given these two points, in my mind anything other than making
>
> .method($foo);
>
> mean
>
> $_.method($foo);
>
> is utterly absurd. If it means $_.method($foo) outside a method
> definition and $?SELF.method($foo) inside one then I think it's a
> reasonable expectation for people learning Perl 6 to throw up their
> hands and start complaining loudly (and possibly going back to their
> previous language of choice).
I don't think that is what Rob is saying at all. My read:
.method($foo);
always means:
$_.method($foo);
and
$self.method($foo);
always means
$?SELF.method($foo);
The former is consistent with the rest of Perl 6, and the latter is
consistent with most of Perl 5 OO code in the wild.
My only stance is that, given there is no clearly sexy solution, at
least I can take `$self` home to meet my Mom.
Cheers, Brian
Re: ./method
On 5/15/05, Juerd <[EMAIL PROTECTED]> 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
Re: ./method
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 So the rule is: One-character operator --> call on $_ Two-character operator --> call on $?SELF" Damian
Re: junctions vs English negatives.
Luke wrote:
Hmm. I'll just [mention] that if != is implemented like this:
multi sub infix: (Any|Junction $a, Any|Junction $b) {
!($a == $b);
}
Then it Just Works.
I'd be fine with the dwimmy version if that is the underlying rule, since then
the behaviour isn't a special case, and it's easy to explain that the magic of
the C is being applied before the magic of junctions.
Damian
Re: ./method
On Sun, May 15, 2005 at 08:30:06PM -0400, Rob Kinyon wrote: : On 5/15/05, Juerd <[EMAIL PROTECTED]> 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? ../ 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
Re: ./method
Damian Conway <[EMAIL PROTECTED]> 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? -- matt diephouse http://matt.diephouse.com
Re: ./method
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
Re: ./method
On Sun, May 15, 2005 at 08:54:52PM -0400, Matt Diephouse wrote: : Damian Conway <[EMAIL PROTECTED]> 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. 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
Re: junctions vs English negatives.
On Mon, May 16, 2005 at 10:37:13AM +1000, Damian Conway wrote:
: Luke wrote:
:
: >Hmm. I'll just [mention] that if != is implemented like this:
: >
: >multi sub infix: (Any|Junction $a, Any|Junction $b) {
: >!($a == $b);
: >}
: >
: >Then it Just Works.
:
: I'd be fine with the dwimmy version if that is the underlying rule, since
: then the behaviour isn't a special case, and it's easy to explain that the
: magic of the C is being applied before the magic of junctions.
Heh, I knew if I waited long enough I'd see arguments for both sides.
Okay, let's go with the "not raising". Ain't lingristiks wunnerfle.
Larry
