HaloO,
John M. Dlugosz wrote:
Perl 6 has a concept of a candidate list. The candidate list are
those that could handle the call, typically inherited methods and
multi variations.
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
It seems
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on the list. Therefore, there
is
On Sat, Apr 19, 2008 at 08:00:07AM -, John M. Dlugosz wrote:
: Perl 6 has a concept of a candidate list. The candidate list are those
that could handle the call, typically inherited methods and multi variations.
:
: It seems that multi variations, at least with respect to the semicolon
HaloO,
John M. Dlugosz wrote:
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
Candidate set would be a better term. It is a subset of all long names
of a multi in a lexical scope.
List, not set, because it is ordered. nextsame/nextwith/etc. are
described as invoking the next candidate on
I'd have to agree.
I also think that .foo should always mean $_.foo in methods, without causing
any errors if $?SELF =:= $_ becomes false.
OK. There is a lot of historical threads on the subject and already a lot of
legacy in the Perl6 language.
OK - As I understand it, this is what A12
On Thu, July 14, 2005 10:47 am, Autrijus Tang said:
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
On 7/14/05, Larry Wall [EMAIL PROTECTED] wrote:
Certainly. The problem is that there are too many viable alternatives,
and half of everyone hates half of the alternatives.
You will know I'm no longer a benevolent dictator when I start to enjoy
watching people squirm every time I change my
Aankhen skribis 2005-07-14 12:39 (+0530):
Well, you've certainly got everyone flustered enough that they'll be
overjoyed even if you pick the alternative they hated the most... :-)
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation, let me just
give up my baby to the other woman by saying:
* It's
If this were a straw poll, I'd say...
1. Meaning of $_
.method should mean $_.method always. Making it into a runtime
error is extremely awkward; a compile-time error with detailed
explanataion is acceptable but suboptimal.
2. Topicalization of $?SELF
Neutral on this -- I can
On Thu, Jul 14, 2005 at 05:37:38PM +0200, Carl Mäsak wrote:
On 7/14/05, Juerd [EMAIL PROTECTED] wrote:
It's just a Solomon judgement situation. That can work out well, but I
really hate when it's forced and used to test patience.
If Juerd is right about this being a solomonian situation,
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent choice that will
serve the community well.
Would this
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
: currently is:
:
: From inside another method or submethod:
:
: - a submethod should only be called from the class which defines it.
This doesn't sound right to me.
Larry,
Thanks for the detailed reply. Just a few more questions and I think I
can get this into the metamodel :)
On Jul 14, 2005, at 3:40 PM, Larry Wall wrote:
On Wed, Jul 13, 2005 at 07:27:52PM -0400, Stevan Little wrote:
: The way I am viewing the notion of current class for submethods
:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
it'll always be construed as unambigous. You could go so far as to
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: A submethod is simply a method that says These
: aren't the droids you're looking for if you call it via either SMD
: or MMD dispatch and the first invocant isn't of the exact run-time
: type of the lexical class. In other words,
Larry,
Thanks much, this all makes sense. :)
Thanks,
Stevan
On Jul 14, 2005, at 4:54 PM, Larry Wall wrote:
On Thu, Jul 14, 2005 at 04:31:07PM -0400, Stevan Little wrote:
: Now, the metamodel currently does not have MMD, and I think next
: METHOD is not as relevant in SMD. So would it make
On Thu, Jul 14, 2005 at 01:39:44PM -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
If .method always
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous. If you say
use dot;
ICK!
Larry Wall skribis 2005-07-14 13:39 (-0700):
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the time, but only when unambiguous.
Thus it never means $?SELF.foo without $_ being
Yuval Kogman skribis 2005-07-15 1:09 (+0300):
use dot;
If we have pragmas for the 99 Perl6's that every wacko wants to
have, we won't have any readability.
The syntax needs to be consistent and useful, even at the price of
some danger.
Agreed.
I don't want to be using a language
On Fri, Jul 15, 2005 at 01:09:57AM +0300, Yuval Kogman wrote:
On Thu, Jul 14, 2005 at 13:39:44 -0700, Larry Wall wrote:
On Thu, Jul 14, 2005 at 12:55:26PM -0400, Nathan Gray wrote:
: So long as .foo (pretty please) means $_.foo all the time (with sugar on
: top?).
It means that all the
On Thu, Jul 14, 2005 at 09:38:45PM +0200, Juerd wrote:
Nathan Gray skribis 2005-07-14 12:55 (-0400):
Autrijus joked? about $?.method once (instead of ./method), in case we
need any more bad alternatives for $?SELF.method. But I also trust
@larry, or %larry, or even $larry, to make a decent
On Wed, Jul 13, 2005 at 12:51:49PM -0400, Stevan Little wrote:
: Hello,
:
: More questions for the metamodel. I am trying to add proper submethod
: and private method handling and I have a question about method
: resolution order as a whole. I asked a similar question last week, but
: this
On Tue, Jul 12, 2005 at 04:43:06PM +0530, Aankhen wrote:
: I agree with what is being said here. `.method` is a great way to
: eliminate a lot of repetitive, tedious typing. Surely there is a
: viable alternative that doesn't involve outlawing it?
Certainly. The problem is that there are too
Larry,
On Jul 13, 2005, at 2:30 PM, Larry Wall wrote:
: The Syn/Apoc seem to indicate that methods and submethods of the same
: name can coexist. So the class definition itself is legal. However,
it
: brings up an issue when it comes time to call bar().
If the Syn/Apoc is giving that
Larry Wall skribis 2005-07-11 18:29 (-0700):
is that we simply outlaw .foo notation at *compile* time in those
scopes where we know (at compile time) that $_ and $?SELF diverge.
In such a scope you *must* specify $_ or $?SELF (or equivalent).
What?
That makes having a default at
I feel a me too post is in order.
I've written code that is 2-3 levels of nested given/when in a
method of an object that wasn't the topic.
I did not feel confused at all, juggling .foo and ./foo, which are
visually distinct, and different to type. They convey a big
difference of meaning, even
On 7/12/05, Juerd [EMAIL PROTECTED] wrote:
[snip]
Disallowing .method here means a huge step back in time. Back to
$_.method or $object.method.
[snip]
I agree with what is being said here. `.method` is a great way to
eliminate a lot of repetitive, tedious typing. Surely there is a
viable
Autrijus Tang wrote:
The compiler, in turn inspect whether there's an bound $_ in scope
with $?SELF set. It is not trivial, because this should work:
sub baz (c) { c() }
method foo { baz { .bar } } # $_ is free in inner closure
But this needs to fail:
sub baz (c) { c(1) }
On Tue, Jul 12, 2005 at 12:36:23PM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
: On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: : On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: : The obvious thought is to have yet
On Sat, 9 Jul 2005, Robin Redeker wrote:
I wasn't thinking 'cool', I was thinking 'visually distinctive and
mnemonic'. I actually think o. is cooler.
Yes, i would like o. more too. At least it doesn't introduce
a completly meaningless '/' preceded by a '.'.
Hmmm... I am one of those who
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote:
: Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_
: like it! Thus, how about making '/' less meaningless, i.e. more
: meaningful, in more general situations?!?
Um, do you have a specific proposal? Like
Larry~
On 7/11/05, Larry Wall [EMAIL PROTECTED] wrote:
On Mon, Jul 11, 2005 at 11:14:18AM +0200, Michele Dondi wrote:
: Hmmm... I am one of those who likes ./ more, instead. I mean, I _really_
: like it! Thus, how about making '/' less meaningless, i.e. more
: meaningful, in more general
On Mon, Jul 11, 2005 at 04:50:56PM -0400, Matt Fowles wrote:
: Yay! I guess I will take this moment to resuggest @^ as a list of
: invocants and $^ =:= @^[0]. I like how the ^ kinda points you the
: right way, also visually distinctive and doesn't get in the way of
: $_...
I don't see much use
(Cross-posting the new ruling from p6l to p6c to discuss implementation
strategy)
On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
{
let $Larry.decisive = 1;
Okay, this is what we're gonna do. We're gonna go back pretty close to
where we were originally, but with a
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it is set, then the parser can emit
: .method as $_.method, instead
On Mon, Jul 11, 2005 at 09:04:54PM -0700, Larry Wall wrote:
On Tue, Jul 12, 2005 at 10:17:01AM +0800, Autrijus Tang wrote:
: On Mon, Jul 11, 2005 at 06:29:28PM -0700, Larry Wall wrote:
: The obvious thought is to have yet another magical, $^H like flag, to
: denote the current dialect. If it
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote:
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
On Fri, Jul 08, 2005 at 08:50:35AM -0500, Jonathan Scott Duff wrote:
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly
On Fri, Jul 08, 2005 at 08:28:34PM +0200, Robin Redeker wrote:
: On Fri, Jul 08, 2005 at 10:07:24AM -0400, Stevan Little wrote:
: I have never understood what is wrong with this:
:
: method foo ($self: $bar) {
: $self.baz()
: }
:
: Thats a fine option to have.
: But therecomes another
On Fri, Jul 08, 2005 at 05:43:01PM +0200, Robin Redeker wrote:
: Maybe per .-file in the home-directory, like .vimrc ...
Only if pulled in with a use. I don't want to see Perl programs
implicitly starting in a variant language. Dialects must be declared.
Otherwise you're in a situation like
On Thu, Jul 07, 2005 at 08:12:17PM -0700, Larry Wall wrote:
The basic problem is that I always hated looking at C++ and not knowing
whether I was looking at a function or a method, so I'm not going to
make standard Perl work like that. On the other hand, there's always
use self ;
to
On Fri, Jul 08, 2005 at 08:10:00AM +0200, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language,
What a way to win
On Jul 8, 2005, at 2:10 AM, Robin Redeker wrote:
And what will be the default syntax to call
a method on self? If everyone has completly other
preferences about this, for example this horrible ./method()
syntax, which completly wont fit into the language, whose
favorite will be the default?
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self? (like in C++)
Because perl can't distinguish between the method foo() and the
On Thu, Jul 07, 2005 at 04:08:17PM -0500, Jonathan Scott Duff wrote:
On Thu, Jul 07, 2005 at 10:32:37PM +0200, Robin Redeker wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self?
On 7/8/05, Robin Redeker [EMAIL PROTECTED] wrote:
Hi,
i just wanted to ask what was about the method calling syntax on
$self, and why does
method ()
not work for calling a method on $self? (like in C++)
IIRC, Larry wants to be able to distinguish method calls from sub
calls, so that
The basic problem is that I always hated looking at C++ and not knowing
whether I was looking at a function or a method, so I'm not going to
make standard Perl work like that. On the other hand, there's always
use self ;
to go with everyone else's preferences:
use self .
use self `
LW == Larry Wall [EMAIL PROTECTED] writes:
LW to go with everyone else's preferences:
LW use self .
LW use self `
LW use self ·
LW use self ..
LW use self ^.
LW use self i.
LW use self o.
LW use self ¤.
LW use self me.
LW use self
On Mon, Jun 20, 2005 at 07:34:57PM -0400, Kurt wrote:
On 6/18/05, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it. I personally find ./method prettier and easier to
type than any of the alternatives.
I don't like it because I think
What does this have to do with perl6-internals? F-up to p6l.
Matthew Zimmerman skribis 2005-06-21 11:27 (-0400):
$self-_fraction * $self-concentration +
$s2-_fraction * $s2-concentration
You can still write it like that, if you declare a
Jonathan Scott Duff skribis 2005-06-21 10:00 (-0500):
I expect that soon after perl6 is released (heck, maybe before it's
released) we'll get tools that will translate perl6 to perl6 while
performing some syntactic manipulation. For instance, it could
explicitize code (replacing ./method with
Juerd wrote:
What does this have to do with perl6-internals? F-up to p6l.
Sorry! Typing faster than my brain is working. Resent to the right list.
If I have a complicated mathematical expression
If you have anything that is complicated, a verbose version should
always be considered, if
[Sorry, sent this to the wrong list by mistake.]
Matthew Zimmerman wrote:
Juerd wrote:
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
On 6/18/05, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it. I personally find ./method prettier and easier to
type than any of the alternatives.
I don't like it because I think method calls should look like method calls,
and the slash
Kurt skribis 2005-06-20 19:34 (-0400):
However, if it remains official, I expect I'll simply be naming my
invocants, as chromatic has suggested.
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
Juerd
--
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Kurt
Kurt skribis 2005-06-20 19:46 (-0400):
On 6/20/05, Juerd wrote:
Or you can just get your self with a simple (module that does)
macro self () { '$?SELF' }
And you could do the same for `./`.
Certainly.
However, there has proven to be much demand for something like ./method,
and in such
John Siracusa wrote:
On 6/18/05 8:28 PM, Juerd wrote:
The unix shell and things resembling it will still be in use much fifteen
years after today, Perl 5 will not.
Ooo, a bold prediction :)
Heh, it is indeed. And it means given the 16,000,000 lines of Perl in
CPAN, we only have to keep
On Jun 18, 2005, at 9:24 PM, Damian Conway wrote:
chromatic wrote:
I find it ugly enough that I plan to name my invocants explicitly.
...which should be construed as a *feature* of the current syntax. ;-)
Damian
In that case, why do we have this feature?
Seriously. Are default
David Storrs skribis 2005-06-19 13:45 (-0400):
Seriously. Are default invocants really such a good idea?
Yes, as long as the default is $_.
./method doesn't use a default invocant. It calls method on the current
invocant, which happens to be available as $?SELF: that doesn't mean it
defaults
The reason we ended up at ./method was simply because it was the best
suggestion anyone had.
Compared to the previous suggestions it was way ahead.
It's other advantage is that (except for on nordic keyboards) dot and
slash are generally right next to each other, so the expense of using it
On 6/18/05 12:23 AM, Adam Kennedy wrote:
The reason we ended up at ./method was simply because it was the best
suggestion anyone had.
That's what I'm trying to remedy :)
It's other advantage is that (except for on nordic keyboards) dot and
slash are generally right next to each other, so the
At 7:52 AM -0400 6/18/05, John Siracusa wrote:
That actually looks more private to me. Let's line 'em up again:
PUBLIC PRIVATE
-- --
./method() .:method()
[EMAIL PROTECTED]() .:method()
.method() .:method()
.:method() .method()
.:method()
Darren Duncan skribis 2005-06-18 11:40 (-0700):
item invocation syntax was exactly the same but with the
consideration that all private items have a ':' as the first
character in their otherwise alphanumeric names (the ':' looks like
part of an operator but it isn't).
Except for
On 6/18/05 2:40 PM, Darren Duncan wrote:
As I recall, it was decided for a broad scope that public and private
item invocation syntax was exactly the same but with the
consideration that all private items have a ':' as the first
character in their otherwise alphanumeric names (the ':' looks
John Siracusa skribis 2005-06-18 19:55 (-0400):
./method() ./:method()
[EMAIL PROTECTED]() .@:method()
.method() .:method()
.-method() .-:method()
[...]
./method() ./:method() # worst
Why exactly is the slash not acceptable for you? Almost everyone has
said
On 6/18/05 7:54 PM, Juerd wrote:
[EMAIL PROTECTED]() .@:method()
In Perl, @ has a VERY strong association with arrays, so except for
specialised frameworks, I recommend against using it for other purposes.
The / character has very strong associations in nearly every programming
John Siracusa skribis 2005-06-18 20:16 (-0400):
On 6/18/05 7:54 PM, Juerd wrote:
In Perl, @ has a VERY strong association with arrays, so except for
specialised frameworks, I recommend against using it for other purposes.
The / character has very strong associations in nearly every
On 6/18/05 8:11 PM, Juerd wrote:
John Siracusa skribis 2005-06-18 19:55 (-0400):
./method() ./:method()
[EMAIL PROTECTED]() .@:method()
.method() .:method()
.-method() .-:method()
[...]
./method() ./:method() # worst
Why exactly is the slash not
On 6/18/05 8:28 PM, Juerd wrote:
The unix shell and things resembling it will still be in use much fifteen
years after today, Perl 5 will not.
Ooo, a bold prediction :)
-John
John Siracusa skribis 2005-06-18 20:35 (-0400):
On 6/18/05 8:28 PM, Juerd wrote:
The unix shell and things resembling it will still be in use much fifteen
years after today, Perl 5 will not.
Ooo, a bold prediction :)
Do you really think so? I think that there is no way that Perl 5 can
John Siracusa skribis 2005-06-18 20:33 (-0400):
I literally didn't even consider that it could be some sort of new
syntax--and that's saying a lot considering I was reading p6l.
You missed a 33 message thread that was referred to many times. Such
things happen, I am surprised by new inventions
On Sun, 2005-06-19 at 02:11 +0200, Juerd wrote:
Why exactly is the slash not acceptable for you? Almost everyone has
said they like it.
I find it ugly enough that I plan to name my invocants explicitly.
-- c
On 6/18/05 8:55 PM, Juerd wrote:
I'm just hoping there's an alternative that everyone will like better
As long as I'm part of everyone, that won't happen. I've listed
numerous possibilities for myself, and found none that I liked better
than ./method. I don't think you can come up with a
chromatic wrote:
I find it ugly enough that I plan to name my invocants explicitly.
...which should be construed as a *feature* of the current syntax. ;-)
Damian
At 1:54 AM +0200 6/19/05, Juerd wrote:
Except for attributes, which play a different game: the colon comes
*instead* of the dot as the twigil, while the accessor method gets : in
front of its name. If I recall correctly, the syntax is very misleading
in that it is NOT part of the name.
I would
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:
On 6/17/05 10:42 PM, John Siracusa wrote:
[...] I'm not, however, buying Damian's argument here:
On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said:
This missing
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote:
But the truth is that /
really does look file-path-y to me, and just plain old ugly. I
think at
least two other people had similar reactions (Martin Kuehl and Carl
Franks).
David Storrs, reporting to show solidarity, sir(acusa)!
Maybe
On 6/17/05 10:56 PM, David Storrs wrote:
I'm not fond of .:: because I don't think it's sufficiently visually
distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
On 5/15/05, Juerd [EMAIL PROTECTED] 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.
This syntax doesn't clash with anything,
On 5/19/05, Martin Kuehl [EMAIL PROTECTED] wrote:
I have tried, but I can't make myself like it.
aolI'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
HaloO Juerd,
you wrote:
(This illustrates my feeling about @foo[] being the same as @foo. It
feels inconsistent with foo() not being foo.)
I have the same feeling. But I would like @foo[] to mean something else
than plain @foo which should be---hmm, how shall I put that---a
underefenced reference
Damian Conway wrote:
Now, personally, I would like to see a short-cut for *both* types of
method call,...
Looks like this syntax is now .method and ./method plus the private
counterpart .:method.
If I have .foo() as $_.foo(), then I can get unary method call on
invocant very easily, even if
On 15/05/05 22:48 +0100, Matthew Walton wrote:
I don't think that is what Rob is saying at all.
It wasn't aimed entirely at Rob. I have a bad habit on mailing lists of
vaguely replying to the entire thread without remembering who said what
and being too lazy to check.
My read:
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 $_
All~
I feel like people have lost track of one of the initial arguments for
having C .method == $?SELF.method . Currently, all of
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward .foo also refering to $?SELF. But as we all know
the is
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward .foo also refering to $?SELF. But as we all know
the is optional on function calls...
I believe you are thinking in Perl 5.
Hi,
wolverian wrote:
On Mon, May 16, 2005 at 02:26:02PM -0400, Matt Fowles wrote:
$.foo
@.foo
%.foo
and their ilk operate on the current invocant, $?SELF. This leads
naturally toward .foo also refering to $?SELF. But as we all know
the is optional on function calls...
I believe you
Ingo Blechschmidt skribis 2005-05-16 21:28 (+0200):
yes, but with parens, it *is* a call:
sub foo(...) {...}
say foo(...); # Calls foo
say foo(...); # Calls foo
say foo; # CODE(0x) or somesuch
Only because there's an implicit . there. This is like saying that
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
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
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
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:
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
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)
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
(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
1 - 100 of 175 matches
Mail list logo
