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
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
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
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 se
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 suboptim
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 say
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
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 th
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 languag
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 $_ bei
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;
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 alwa
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 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 wor
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
say
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 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
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 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 situ
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 a
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:
* "I
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 t
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 chang
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 impressi
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 ma
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 time
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
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 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
viab
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
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
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
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
(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 wit
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 f
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 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 maybe
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 lik
On 7/9/05, Robin Redeker <[EMAIL PROTECTED]> wrote:
> On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> > : > Why does it have to be some sugared syntax when you can just simple
> > : > name it in the parameter list?
> > :
> > : Yes, but there seem to be quite some people who want
> > :
On Sat, Jul 09, 2005 at 07:36:10AM -0700, Larry Wall wrote:
> : > Why does it have to be some sugared syntax when you can just simple
> : > name it in the parameter list?
> :
> : Yes, but there seem to be quite some people who want
> : a 'cool' syntax for it. (ie. ./method ()).
>
> I wasn't thi
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 ha
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 anoth
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 c
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 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?
None
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 f
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 "";
> "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>
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 sel
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
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 metho
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
[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 `./`.
C
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 only
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
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 decla
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 th
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 i
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: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
--
http://convolution.nl/maak_juerd_bli
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 sepa
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
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 invoc
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 th
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
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
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 wit
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
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
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
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
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 sl
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 prog
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
l
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 ha
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
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 attribu
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()
.:metho
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 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
is
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?
.::internal_value(
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 .:
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 d
On 5/19/05, Martin Kuehl <[EMAIL PROTECTED]> wrote:
> I have tried, but I can't make myself like it.
I'm afraid I have to agree.
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
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 w
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 method
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 referenc
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
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...
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
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 o
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
> 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:
>
>.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()
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
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
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 w
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:
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 $
1 - 100 of 179 matches
Mail list logo
