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
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
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. E
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
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 i
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.
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 lege
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
> > "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 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
On Sun, 2002-04-14 at 16:41, Dave Mitchell wrote:
> On Sat, Apr 13, 2002 at 05:07:37PM -0700, Larry Wall wrote:
[...]
> > my $self = invocant;
> >
> > or some such mummery. But that seems a bit retro.
>
> But now we have endless possibilities for
> $self.ish
> $self.less
> $self
> Yay, tagmemics! :) Shall I offer an "Intro to Linguistics for Perl 6
> Developers" class? That would be fun!
Please!!!
-Miko "Wouldn't Know a Tagmemic if it Bit Him on the Parse" O'Sullivan
On Mon, Apr 15, 2002 at 11:03:15PM -0400, John Siracusa wrote:
> On 4/15/02 10:24 PM, Larry Wall wrote:
> > The main point of doing this isn't really the migration from Perl 5,
> > but a basic underlying philosophy of linguistics known as tagmemics.
> ("tagmemics"? ;)
Yay, tagmemics! :) Shall
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 th
[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 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 the
Luke Palmer wrote:
> > More interestingly, it may also be that, by default, the C (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. Not
> > $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, pu
On 4/15/02 1:16 AM, Damian Conway wrote:
> More interestingly, it may also be that, by default, the C (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 ha
On Mon, 15 Apr 2002, Damian Conway wrote:
> More interestingly, it may also be that, by default, the C (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 Flintston
> 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
w
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 mummer
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
[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 guesses
> 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 par
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
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 com
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.
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 sub
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
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 <> {
> pr
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 C, and C only,
introduces a to
Trey Harris wrote:
>
> Oops, caught my own mistake...
> Because $_ is always the topic, which is always the first parameter to a
> block, which in subroutines is @_[0], right? So in a sub, $_ == @_[0].
> The only question I have is if you modify @_ with a shift, does $_
> continue to point at t
On Wed, Apr 10, 2002 at 05:47:01PM -0500, Allison Randal wrote:
> I'm in favor of the standardized variable name. It is a restriction, but
> not an onerous one. I've never used anything but $self, and I'm sure it
> would be easy to adapt to whatever else was chosen. Are there any
> statistics avai
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 access
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(shi
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
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;
> }
> pr
On Wed, Apr 10, 2002 at 08:47:17PM -0400, Melvin Smith wrote:
> At 08:04 AM 4/11/2002 +1000, Damian Conway wrote:
> >Of course, the problem is then: what should the name of this topicalizer
> >variable be? The main options are:
> >
> > $self
> > $me
> > $I
> > $this
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 C would work as well.
Yes, something like that wo
- 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'
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 s
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
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 wri
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()? Ass
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;
> }
> pri
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 "Done!";
sub printRec {
chomp;
print
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 imposs
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. C is doing a slightly different job
: > > anyway. And instance variables are *not* the same as 'normal'
: > > variables, they hang off a
> "David" == David Whipp <[EMAIL PROTECTED]> writes:
David> If every object has a C method (C?), 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 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. C 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,
> Ah, but I think the mnemonic value of the '.' more than earns its keep
> here. C 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 Perl 5+i) and
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. Lik
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 $_,
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. L
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 th
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 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
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
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
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
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
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! ;-)
Exact
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
>
> 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 C as discussed. That or
C. I think the latter mak
> > "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() => $_->f
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
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 be
> 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, wh
"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 fee
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 encodi
tance or class
Can't say I'm keen on that at all. We already have a '..' operator
(admittedly it's binary), 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 bina
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
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 t
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
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 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]>
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!
>
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 extr
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 do
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 t
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 inv
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
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
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
>
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 inv
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
"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 woul
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
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; # sy
t". If you're going to need to access an outer
> topic within a nested topicalizer, you should define a named
> variable/parameter ("method icial ($self:..."). This is the path we've
> taken with other nested topicalizers.
Yes, yes, be explicit. If the current topic
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
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 C with
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 C within. We're talking about how to make .foo
mean self.foo reg
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) { ...
> 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'?
> : 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
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
ic. 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, c
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 "".
S
1 - 100 of 105 matches
Mail list logo
