I came across this slight annoyance working in Perl 5 today:
sub preserve() {...}
sub foo {
preserve {
$_[0]-bar;
}
}
That didn't call bar on the invocant of foo, but rather on undef,
because preserve's block was a hiding sub.
Perl 6 is making it easier
On Mon, Sep 20, 2004 at 07:25:14AM -0600, Luke Palmer wrote:
: Perl 6 is making it easier to define custom block constructs like this
: one. I worry about:
:
: method foo () {
: preserve {
: .bar;
: }
: }
:
: This one's a tad more subtle. Normally preserve's
On Tue, Apr 16, 2002 at 09:29:21AM -0400, Miko O'Sullivan wrote:
Wouldn't Know a Tagmemic if it Bit Him on the Parse
Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I
like it! :)
Allison
Wouldn't Know a Tagmemic if it Bit Him on the Parse
Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I
like it! :)
You got it!
I hope this isn't too off topic, but... is the word tagmeme somehow
related to the urban legend concept of a cultural meme?
-Miko
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
AKA the
Miko O'Sullivan writes:
: Wouldn't Know a Tagmemic if it Bit Him on the Parse
:
: Ooh, can I steal that as a title? (Though I'll s/Tagmemic/Tagmeme/.) I
: like it! :)
:
: You got it!
:
: I hope this isn't too off topic, but... is the word tagmeme somehow
: related to the urban legend
On Tue, 16 Apr 2002 09:34:36 -0700 (PDT), Larry Wall [EMAIL PROTECTED] wrote:
Pike predates Dawkins, who I believe made up the term.
(Could be wrong about that.) They are similar concepts, however, in
that a tagmeme is a psychological linguistic construct that propagates
culturally. It's
Andy Wardley [EMAIL PROTECTED] writes:
On Mon, Apr 15, 2002 at 07:24:13PM -0700, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing
Piers Cawley writes:
: Andy Wardley [EMAIL PROTECTED] writes:
: Hang on, now I'm a little confused - I thought that hashes were supposed
: to keep their % sigil. So shouldn't that be %foo.keys or %foo.{keys}?
: But then that would then violate the uniform access principle because
: hash/key
Juanma Barranquero wrote:
On _THE SELFISH GENE_ Dawkins says he coined the term, which was a more
euphonic version of mimeme:
On quickly scanning that message I read the last word as mini-me, which
brought up some *very* unlikely associations! :-)
Damian
--
So, Mr. Evil...
It's Dr. Evil, I
On Mon, 15 Apr 2002, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new
On 4/15/02 1:16 AM, Damian Conway wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
$foo.bar_attr = 1;
could also be written:
$foo.{bar_attr} = 1;
and still
$foo.{bar_attr} = 1;
This would help Perl 6 support legacy Perl 5 OO code
How? Perl 5 code doesn't use ., and if Perl 5 code has to be changed
anyway, why not change it all the way?
Because changing:
$foo-{bar_attr}
to:
$foo.{bar_attr}
is a generic, purely
Luke Palmer wrote:
More interestingly, it may also be that, by default, the Coperator:{} (i.e.
hash-look-up) method of a class invokes the accessor of the same name as the
key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintstone;
No.
On 4/15/02 5:16 PM, Damian Conway wrote:
if we don't support this, people will be forever having to create Perl 6
adapter classes just so that they can make use of legacy Perl 5 code. :-(
Okay, how about making it a pragma that's not enabled by default? So all
those Perl 5 porters can do
[EMAIL PROTECTED] writes:
: On 4/15/02 5:16 PM, Damian Conway wrote:
: if we don't support this, people will be forever having to create Perl 6
: adapter classes just so that they can make use of legacy Perl 5 code. :-(
:
: Okay, how about making it a pragma that's not enabled by default? So
On 4/15/02 10:24 PM, Larry Wall wrote:
So the main reason that objects can function as hashes is so that the
user can poke an object into an interface expecting a hash and have it
make sense, to the extent that the object is willing to be viewed like
that.
Sure, by why should that be the
On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote:
Of course, one of the big reasons we went with $self was the pun:
my $self = shift;
which we won't have now. Unless we always hide the invocant and
force you to say
my $self = invocant;
or some such mummery. But
One of the features I like about Eiffel is what Meyer calls the Uniform
Access principle...It sounds as though Perl 6 is heading towards supporting
this. Have we actually got there?
That's the intention, yes.
The details still need to be nutted out, but it seems very likely that if you
On Fri, Apr 12, 2002 at 05:34:13PM -0700, Glenn Linderman wrote:
Allison Randal wrote:
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
$_ becomes lexical
Sound logic. And it almost did go that way. But subs that access the
current $_ directly are far too common, and far
Allison Randal wrote:
What if $_ were dynamically scoped, but only for subroutines? Dynamic
scoping is not necessarily the same thing as a global $_. It would
merely pretend (only for $_) that the subroutine had been defined in the
scope where it was evaluated. But that could get you into
There'd be an interaction between is topic_preserving, default parameter
values, and explicit parameter values which should be clarified. Now I
understand why someone suggested using //= $_ instead of is
topic_preserving, somewhere along the line. Clearly if the user
supplies the
[EMAIL PROTECTED] writes:
: Dave Mitchell wrote:
:
: The top 20 'my $var' declarations in .pm files in the bleedperl
: distribution:
:
: How *dare* you introduce hard data into this discussion!
: Next you'll be wanting to deal in actual facts rather than personal
: opinion and sheer
On Sat, Apr 13, 2002 at 08:53:41AM -0700, Glenn Linderman wrote:
Off hand, it seems like defaulting to is dynamic_topic would make
more of those common useful $_-dependent subroutines work without
change, but I guess if the perl 5 to 6 translator can detect use of $_
before definition of $_
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
On Fri, 2002-04-12 at 04:26, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write
On Fri, Apr 12, 2002 at 09:26:45AM +0100, Piers Cawley wrote:
Trey Harris [EMAIL PROTECTED] writes:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()?
On Fri, 2002-04-12 at 09:52, Jonathan Scott Duff wrote:
On Fri, Apr 12, 2002 at 09:40:16AM -0400, Aaron Sherman wrote:
sub printRec() { printRec($_) } # No args, therefore no new topic.
sub printRec($rec) { .chomp; print :$rec:\n } # 1 arg
I think was he was saying is
- Original Message -
From: Graham Barr [EMAIL PROTECTED]
Hm, I wonder if
sub printRec($rec=$_) { ... }
or someother way to specify that the current topic be used
as a default argument, might be possible
Would it would be reasonable to have given default to the caller's topic?
In a message dated Fri, 12 Apr 2002, Ashley Winters writes:
Would it would be reasonable to have given default to the caller's topic?
sub printRec {
given {
# $_ is now the caller's topic in this scope
}
}
Perhaps Cgiven caller.topic {} would work as well.
Yes, something
On Fri, 12 Apr 2002, Trey Harris wrote:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
}
printRec
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
Couldn't you do it with old-style Perl5 subs?
sub printRec {
my $p = chomp(shift // $_);
print :$_:\n
}
Or am _I_ missing something?
That definitely won't work (aside from the $p/$_ swap which I assume is
unintentional),
Oops, caught my own mistake...
In a message dated Fri, 12 Apr 2002, Trey Harris writes:
In a message dated Fri, 12 Apr 2002, Luke Palmer writes:
sub printRec {
my $p = chomp(shift // $_);
print :$_:\n
}
[Should be equivalent to]
sub printRec {
my $p = chomp(shift //
On Thu, Apr 11, 2002 at 08:49:40AM -0700, Larry Wall wrote:
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: $foo.instancevar = 7;
:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
That is, in fact, calling an accessor
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
$_ becomes lexical
$_ gets aliased to the first topic of a given clause (hence changes
value more often, but the lexical scoping helps reduce that impact)
Okay. But it sounds like you're saying that Cgiven, and Cgiven only,
On Fri, Apr 12, 2002 at 02:44:38AM -0400, Trey Harris wrote:
I think I've missed something, even after poring over the archives for
some hours looking for the answer. How does one write defaulting
subroutines a la builtins like print() and chomp()? Assume the code:
for {
printRec;
Okay, first thing to keep in mind, this hasn't been finally-finalized
yet. Alot was hashed out in the process of proofing E4, but there will
be more to come.
On Fri, Apr 12, 2002 at 07:39:17PM -0400, Trey Harris wrote:
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
$_ becomes
Allison Randal wrote:
In a message dated Fri, 12 Apr 2002, Glenn Linderman writes:
$_ becomes lexical
Sound logic. And it almost did go that way. But subs that access the
current $_ directly are far too common, and far to useful.
One thing I'm missing is how those common useful subs that
Dave Mitchell wrote:
The top 20 'my $var' declarations in .pm files in the bleedperl
distribution:
How *dare* you introduce hard data into this discussion!
Next you'll be wanting to deal in actual facts rather than personal
opinion and sheer guesses!!
;-)
Thanks, Dave. Very illuminating.
On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
Ah, but I think the mnemonic value of the '.' more than earns its keep
here. Cour $foo is private is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol
Aaron Sherman writes:
: On Thu, 2002-04-11 at 00:42, Luke Palmer wrote:
: Ah, but I think the mnemonic value of the '.' more than earns its keep
: here. Cour $foo is private is doing a slightly different job
: anyway. And instance variables are *not* the same as 'normal'
: variables, they
On Thu, 2002-04-11 at 11:49, Larry Wall wrote:
Aaron Sherman writes:
: This should not be allowed.
Well, that depends on what you mean by this. :-)
[...]
: In Perl5 C$object{instancevar} = 7 is just frowned on. In Perl6, I
: thought we had agreed that it would flat out be impossible.
David == David Whipp [EMAIL PROTECTED] writes:
David If every object has a Cclass method (Cref?), then you could
David always call class-methods as class.m2().
Wouldn't that be .class.m2(), or did I miss something in the flurry?
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. -
On Tue, Apr 09, 2002 at 09:56:02PM +0100, Piers Cawley wrote:
Larry Wall [EMAIL PROTECTED] writes:
We're talking about how to make .foo mean self.foo regardless of the
current topic.
Are we? I was looking for a way to unambgiously access the current
object in such a way that
variable/parameter (method icial ($self:...). This is the path we've
taken with other nested topicalizers.
Yes, yes, be explicit. If the current topic is an object, its methods
get invoked by unary dot, be it inside a method or outside a method.
Direction 2 moves into the more exciting but scarier
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
.m2; #
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do
On Wed, Apr 10, 2002 at 10:50:52AM -0700, Glenn Linderman wrote:
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the former, how would you
do the latter?
Should both be allowed to exist? Do both exist? Why do both exist?
David Whipp wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no invocant? If the
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as a class method with no
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current invocant
or as
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an instance method on the current
Glenn Linderman [EMAIL PROTECTED] writes:
Graham Barr wrote:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but does it call it as an
On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote:
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
This is looking more and more horrible Glenn.
I think we need to back off of unmarked subroutines becoming a method
call. That one extra '.'
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
Allison Randal wrote:
Direction 2 moves into the more exciting but scarier realm of alternate
defaults.
It could, but how about an alternative?
Ah-ha, yet a third Direction!
Need there be a unary dot to specify
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
..class.m2: # call static m2 within m1's class, regardless of how m1 was called
Typo. That should be just .class.m2, only one leading '.'.
--
Mark J. REED[EMAIL PROTECTED]
Mark J. Reed wrote
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
..class.m2: # call static m2 within m1's class, regardless
of how m1 was called
Typo. That should be just .class.m2, only one leading '.'.
Wouldn't that be the current topic's class?
Dave.
On Wed, Apr 10, 2002 at 12:12:56PM -0700, David Whipp wrote:
Mark J. Reed wrote
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
..class.m2: # call static m2 within m1's class, regardless
of how m1 was called
Typo. That should be just .class.m2, only one leading '.'.
On Wed, Apr 10, 2002 at 03:03:45PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 07:57:01PM +0100, Piers Cawley wrote:
::m2; # calls global subroutine main::m2
main::m2; # calls global subroutine main::m2
This is looking more and more horrible Glenn.
I think we need to back off
On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote:
I like the following, assumed to be within method m1:
..m2();# call m2 the same way m1 was called, instance or class
This has already been semi-rejected. I agree with the reasoning. Not
that it wouldn't be nice to
), and this new, unary .. doesn't really do
anything remotely similar (cf unary dot, unary _ and unary +, which
have behaviours which are obviously related to the binary forms.).
And haven't we done this discussion already?
--
Piers
It is a truth universally acknowledged that a language
Piers Cawley
This may be a case of keep up at the back, but if that is a
method call,
how do I call a subroutine from within a method ?
[...]
Yes, I know there's several different ways I could do it, but this
approach feels right.
I think this comes does to huffmann encoding: which
David Whipp [EMAIL PROTECTED] writes:
Piers Cawley
This may be a case of keep up at the back, but if that is a
method call,
how do I call a subroutine from within a method ?
[...]
Yes, I know there's several different ways I could do it, but this
approach feels right.
I think
The following syntaxes have been seen:
foo()
.foo()
..foo() ## rejected because .. is different binary op
class.foo()
FooClass.foo()
::foo()
Package::foo()
$foo()
$_.foo()
With a nod to Piers, and with apologes if this is silly in
the context of Perl 6 syntax, what about:
On Wed, Apr 10, 2002 at 03:49:44PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 02:42:58PM -0500, Allison Randal wrote:
I like the following, assumed to be within method m1:
..m2(); # call m2 the same way m1 was called, instance or class
This has already been
On Wed, Apr 10, 2002 at 09:23:23PM +0100, Piers Cawley wrote:
David Whipp [EMAIL PROTECTED] writes:
Thus, the perl5 transalations would be:
foo() = $self-foo()
.foo() = $_-foo()
foo() = foo()
...
For reasons that I can't quite put my finger on at the moment, I
really,
David Whipp [EMAIL PROTECTED] writes:
Thus, the perl5 transalations would be:
foo() = $self-foo()
.foo() = $_-foo()
foo() = foo()
...
Alternative:
$self.foo() = $self-foo() # and can be .foo() when $self is $_
.foo() = $_-foo() # but might be altered by a
$.foo
It's already defined as an instance variable.
I don't think I like that. Instance variables are far more common that
class variables, so why not just $foo, and you could use a compile-time
property for class variables. Like Cis private as discussed. That or
Cis static. I
Allison wrote:
David Whipp [EMAIL PROTECTED] writes:
Thus, the perl5 transalations would be:
foo() = $self-foo()
.foo() = $_-foo()
foo() = foo()
...
Alternative:
$self.foo() = $self-foo() # and can be .foo() when $self is $_
.foo() = $_-foo() #
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
Allison wrote:
$self.foo() = $self-foo() # and can be .foo() when $self is $_
.foo() = $_-foo() # but might be altered by a pragma
foo() = foo()
And welcome back to where we started! ;-)
Exactly! :)
The
At 07:40 PM 4/10/2002 +0100, Piers Cawley wrote:
Melvin Smith [EMAIL PROTECTED] writes:
At 10:50 AM 4/10/2002 -0700, Glenn Linderman wrote:
Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same
At 07:54 PM 4/10/2002 +0100, Piers Cawley wrote:
Graham Barr [EMAIL PROTECTED] writes:
On Wed, Apr 10, 2002 at 01:35:22PM -0400, Mark J. Reed wrote:
On Wed, Apr 10, 2002 at 10:30:25AM -0700, Glenn Linderman wrote:
method m1
{
m2; # calls method m2 in the same class
Yes, but
At 08:04 AM 4/11/2002 +1000, Damian Conway wrote:
And welcome back to where we started! ;-)
Wow there is a lot of blood on the ground here. Must have been messy... :)
Of course, the problem is then: what should the name of this topicalizer
variable be? The main options are:
$self
Melvin Smith wrote
I think that would be just plain bad design, but I'd be happy
if someone showed me a use for it. :)
well, I've been known to do
sub UNIVERSAL::debug
{
my $self = shift;
my $msg = _;
eval {$self=$self-name} if ref($self);
my $timestamp = ...;
my
On Thu, Apr 11, 2002 at 08:04:56AM +1000, Damian Conway wrote:
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant
Allison Randal wrote:
H... this being the case, is there any reason we should ever need to
name the invocant explicitly?
Yes. To make it read-writable.
Perl makes that much easier than most other languages, because you can pass
the invocant by (writable) reference, so you don't need to
On Thu, Apr 11, 2002 at 12:01:58PM +1000, Damian Conway wrote:
Allison Randal wrote:
H... this being the case, is there any reason we should ever need to
name the invocant explicitly?
Yes. To make it read-writable.
Curses! Foiled again! :)
Perl makes that much easier than most
At 04:01 PM 4/10/2002 -0600, Luke Palmer wrote:
$.foo
It's already defined as an instance variable.
I don't think I like that. Instance variables are far more common that
class variables, so why not just $foo, and you could use a compile-time
property for class variables. Like Cis
Damian Conway [EMAIL PROTECTED] writes:
[...]
Reflecting on this, it seems that it would be useful if methods
implicitly did their default topicalization-of-invocant like so:
- $self
rather than just:
- $_
That is, that as well as aliasing the invocant to $_, they also
Luke Palmer [EMAIL PROTECTED] writes:
$.foo
It's already defined as an instance variable.
I don't think I like that. Instance variables are far more common that
class variables, so why not just $foo, and you could use a compile-time
property for class variables. Like Cis
Ah, but I think the mnemonic value of the '.' more than earns its keep
here. Cour $foo is private is doing a slightly different job
anyway. And instance variables are *not* the same as 'normal'
variables, they hang off a different symbol table (or syte, to use
Damian's oh so clever term from
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what about 'me' or 'i' instead of 'self'?
Me [EMAIL PROTECTED] writes:
But suppose you want all .foo to refer to self and not
to the current topic.
What about
given (self) { }
Also, what about
use invocant;
resulting in all method bodies in scope getting an implied
surrounding given (self) { }.
And what
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within. We're talking about how to make .foo
mean self.foo
Larry Wall [EMAIL PROTECTED] writes:
Me writes:
: But suppose you want all .foo to refer to self and not
: to the current topic.
:
: What about
:
: given (self) { }
That wouldn't have the same effect as what we're talking about--it'd be
overruled by any Cgiven within.
Damian Conway writes:
:use invocant 'self';
Hmm. My first inclination is to say it should be something like:
macro self { '%MY.frame.arg[0]' }
But suppose you want all .foo to refer to self and not to the current
topic. It would be problematic to have a macro whose name is .
So
you might say something like this:
use invocant ;
Still a bit odd syntactically, however.
Perhaps a bare:
use invocant;
overrides unary dot within the lexical scope, causing it to default to using
each method's _[0], rather than $_.
One is vaguely tempted to make
Damian Conway writes:
: Fortunately, Igority is transitive...
:
: I thought that was maxim was: Igorance is blithth.
That's not a maxim, that's a minim.
Larry
: I thought that was maxim was: Igorance is blithth.
That's not a maxim, that's a minim.
No need to get all crotchet-y.
Damian
Piers == Piers Cawley [EMAIL PROTECTED] writes:
Piers So, is there any chance that we'll be able to do:
Piers class ical {
Piers use object_name '$self';
Piers method ical {
Piers given $self.ology {
Piers ... { $self.ish }
Piers }
Piers }
Piers }
You
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit parameters, you can always write:
method
Damian Conway [EMAIL PROTECTED] writes:
Piers asked:
So, is there any chance that we'll be able to do:
class ical {
use object_name '$self';
method ical {
given $self.ology {
... { $self.ish }
}
}
}
Of course, if you're not using explicit
use invocant 'self';
*Much* better name. You see, that's why you're the mad genius and I'm
just the lowly lab assistant. Marthter.
And, given that I'm jutht Larry'th lowly lab aththithtant, that would
theem to make you a meta-Igor!
%-)
Damian
Whilst I've been hacking the perl 6 scheme interpreter I've found
myself using code like the following
method get_token( $self: ) {
given $self.get_char {
when !defined { fail IOException: msg= EOF }
when /\s/ { $self.get_token }
when '(' { $the_left_paren }
98 matches
Mail list logo