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
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
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
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
[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 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
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
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 current
object
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
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 subroutines
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
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 is .
So
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
74 matches
Mail list logo
