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
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 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
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
[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
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 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
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
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
"Mark J. Reed" <[EMAIL PROTECTED]> writes:
> 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
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!
> Need there be a unary dot to speci
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
Allison Randal wrote:
>
> 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
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
Larry wrote:
> : > > 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
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
> > 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
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
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:
> "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> }
P
79 matches
Mail list logo
