Re: Perl 6 - Cheerleaders?
On Wed, 31 Oct 2001, David Nesting wrote: On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote: : Yep, but in Perl5, this was never very clean or obvious to the : casual programmer. Constants have been coming of age in Perl, : and they're kind of scary if they're not constant. On one hand, one might say that a developer changing a constant's binding in order to change its value is probably doing so because he knows what he's doing. As I understand things, constants are really just read-only variables. Do we necessarily want to make a special case out of them and make the variable read-only as well as locking down the symbol itself against re-binding? Upon reflection, I agree with Me. Nesting... I guess if it were some new Perl 6 programmer complaining to me that his constants aren't constant I'd say to that person: It's nobody's fault but yours that you didn't read the language documentation before using 'is const'. It really comes down to adjusting your thinking to understand the difference between a variable and its value. Once you do that, the proposed behaviour of is const makes perfect sense. - D [EMAIL PROTECTED]
Re: Perl 6 - Cheerleaders?
David M. Lloyd [EMAIL PROTECTED] writes: On Wed, 31 Oct 2001, David Nesting wrote: On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote: : Yep, but in Perl5, this was never very clean or obvious to the : casual programmer. Constants have been coming of age in Perl, : and they're kind of scary if they're not constant. On one hand, one might say that a developer changing a constant's binding in order to change its value is probably doing so because he knows what he's doing. As I understand things, constants are really just read-only variables. Do we necessarily want to make a special case out of them and make the variable read-only as well as locking down the symbol itself against re-binding? Upon reflection, I agree with Me. Nesting... I guess if it were some new Perl 6 programmer complaining to me that his constants aren't constant I'd say to that person: It's nobody's fault but yours that you didn't read the language documentation before using 'is const'. It really comes down to adjusting your thinking to understand the difference between a variable and its value. Once you do that, the proposed behaviour of is const makes perfect sense. Do I get to do the 'The name of this song is called Haddock's Eyes' bit from Alice Through The Looking Glass now? -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Static Values and Variable Bindings [was RE: Perl 6 - Cheerleaders?]
On Wed, 31 Oct 2001, David Nesting wrote: On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote: : Yep, but in Perl5, this was never very clean or obvious to the : casual programmer. Constants have been coming of age in Perl, : and they're kind of scary if they're not constant. On one hand, one might say that a developer changing a constant's binding in order to change its value is probably doing so because he knows what he's doing. As I understand things, constants are really just read-only variables. Do we necessarily want to make a special case out of them and make the variable read-only as well as locking down the symbol itself against re-binding? One can always turn that argument around, and say that the developer may want to lock down both the variable's binding and the bound value... because he wants to depend on it (always) doing what he wants it to do. What are we going to have for variable bindings? From Exgesis 2: The type specification tells the compiler that $pre, $in, and $post will only ever be used to store integer values. And because int is in lower-case, the specification also tells the compiler that it's okay to optimize the implementation of the variables, because we promise not to bless them or ascribe any run-time properties to them. Am I correct in inferring from this that: scalar $foo is constant = 0; Could not be blessed, rebound, or ascribe run-time properties?
Re: Perl 6 - Cheerleaders?
John == John Siracusa [EMAIL PROTECTED] writes: John (Can I pre-order the Perl 6 Camel or what? ;) Of course. You'll almost certainly visit the nodes before the subnodes in the documentation. :-) -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL:http://www.stonehenge.com/merlyn/ Perl/Unix/security consulting, Technical writing, Comedy, etc. etc. See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
Re: Perl 6 - Cheerleaders?
On Tue, Oct 30, 2001 at 09:37:39AM -0500, Aaron Sherman wrote: : Yep, but in Perl5, this was never very clean or obvious to the : casual programmer. Constants have been coming of age in Perl, : and they're kind of scary if they're not constant. On one hand, one might say that a developer changing a constant's binding in order to change its value is probably doing so because he knows what he's doing. As I understand things, constants are really just read-only variables. Do we necessarily want to make a special case out of them and make the variable read-only as well as locking down the symbol itself against re-binding? On the other hand, I can see sloppy code where a developer might be doing a bunch of variable aliasing with passed arguments, and might inadvertantly change a constant. Is it possible maybe to throw a warning if warnings are enabled if a constant's symbol is changed like this? Just my thoughts, and I'm not 100% sure they're sensical. David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: Perl 6 - Cheerleaders?
On Tue, Oct 30, 2001 at 04:29:15PM +1100, Damian Conway wrote:
I'd do that like so (using Larry's preferred syntax):
[...]
method INIT ($idval) { $.id := $idval }
Hm... that looks to me like a regular :=; is it?
Yep.
If so, what good is is const if you can override it with
a :=? Am I missing something?
That's a binding, not an assignment.
Cis const means: Once declared cannot be *assigned* to.
But that doesn't mean one can't *bind* a new value to the variable
(which would retain its Cconst-induced unassignability after the binding).
I understand that. I guess what I'm saying is, from a conceptual
standpoint, isn't it misleading to say that class Filesystem provides
a constant called MAXPATHLEN, which is 2048, but then to have
the class override that and change it to 1024?!
I understand that we can wag a finger at the person who does this
and tell them that they will have bad luck for seven years.
On a meta-topic, I see many answers in this list (especially from
Larry and Damian) coming back in the form, well, yeah, but
that's not how it works internally.
I suggest that Perl's internals are very interesting, and certainly
very important, but features such as constants instance variables
have meaning to programmers, and if their application in Perl does
not conform to expectation, programmers are likely to have a
rougher time.
Consider the following Perl 5:
# CREATE CONSTANT
*constant = \7;
print $constant\n;
# TRY TO ASSIGN (THROWS EXCEPTION)
eval { $constant = -7 } or print $@;
print $constant\n;
# TRY TO REBIND (WORKS FINE)
eval { *constant = \-7) } or print $@;
print $constant\n;
Yep, but in Perl5, this was never very clean or obvious to the
casual programmer. Constants have been coming of age in Perl,
and they're kind of scary if they're not constant.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Mon, Oct 29, 2001 at 04:16:24PM -0800, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: 3. If you declare a method *without* any parameter list:
:
: method foo {...}
:
:then the method call arguments (including the invocant?)
:are bound to @_.
:
: Is that correct?
It's what I'm thinking. I have no idea if it's correct.
Was that affirmative of Damian's invocant query as well?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Auto-creation of simple accessors (was: Perl 6 -Cheerleaders?)
Okay, so we've got these guys auto-created if we want:
method foo is lvalue { return $.foo }
(plus or minus the syntax) which lets us do:
$obj.foo = 5;
print $obj.foo;
So, what about simple array accessors?
$obj.colors('red', 'green', 'blue');
$obj.colors = ('red', 'green', 'blue');
$obj.colors = ['red', 'green', 'blue' ];
push $obj.colors, 'red', 'green', 'blue;
pop $obj.colors;
print $obj.colors[1] # @{$obj.colors}[1]?? $obj.colors-[1]?? ;)
Can/will such an accessor be auto-created?
How about hashes (or pairs?)
$obj.fruit(apple = 'red', berry = 'blue');
$obj.fruit = (apple = 'red', berry = 'blue');
$obj.fruit = { apple = 'red', berry = 'blue' };
# Change apple color, but leave the blue berry
$obj.fruit(apple = 'green');
print $obj.fruit('apple'); # green
Regardless of whether something like the above two examples can/will be
auto-created, what would those methods look like anyway? Would they simply
be:
method colors is lvalue { return @.colors }
method fruit is lvalue { return %.fruit }
How many of the examples with the code above support?
-John
Re: Auto-creation of simple accessors (was: Perl 6 - Cheerleaders?)
John Siracusa:
# Okay, so we've got these guys auto-created if we want:
#
# method foo is lvalue { return $.foo }
#
# (plus or minus the syntax) which lets us do:
#
# $obj.foo = 5;
# print $obj.foo;
#
# So, what about simple array accessors?
Please note that these are my best guesses; I'm not a Damian ;^).
# $obj.colors('red', 'green', 'blue');
#
# $obj.colors = ('red', 'green', 'blue');
#
# $obj.colors = ['red', 'green', 'blue' ];
$obj.colors=('red', 'green', 'blue');
#
# push $obj.colors, 'red', 'green', 'blue;
#
# pop $obj.colors;
#
# print $obj.colors[1] # @{$obj.colors}[1]?? $obj.colors-[1]?? ;)
$obj.colors[1]; #If {} and [] force a scalar context, the array return
#value of .colors will turn into an arrayref.
# Can/will such an accessor be auto-created?
#
# How about hashes (or pairs?)
#
# $obj.fruit(apple = 'red', berry = 'blue');
#
# $obj.fruit = (apple = 'red', berry = 'blue');
#
# $obj.fruit = { apple = 'red', berry = 'blue' };
$obj.fruit=(apple = 'red', berry = 'blue');
# # Change apple color, but leave the blue berry
# $obj.fruit(apple = 'green');
#
# print $obj.fruit('apple'); # green
$obj.fruit{apple}
# Regardless of whether something like the above two examples
# can/will be
# auto-created, what would those methods look like anyway?
# Would they simply
# be:
#
# method colors is lvalue { return @.colors }
# method fruit is lvalue { return %.fruit }
BTW, I'm getting this headers thing too, from all @perl.org mailing
lists--not just p5p. Ask, is this your department, and if so can you
fix it?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
Re: Auto-creation of simple accessors (was: Perl 6 -Cheerleaders?)
On 10/30/01 12:13 PM, Brent Dax wrote:
John Siracusa:
Please note that these are my best guesses; I'm not a Damian ;^).
# $obj.colors('red', 'green', 'blue');
#
# $obj.colors = ('red', 'green', 'blue');
#
# $obj.colors = ['red', 'green', 'blue' ];
$obj.colors=('red', 'green', 'blue');
No no, I wasn't presenting alternatives. I want all of those to work! :)
(Okay, well at least most :)
# # Change apple color, but leave the blue berry
# $obj.fruit(apple = 'green');
#
# print $obj.fruit('apple'); # green
$obj.fruit{apple}
Icky, looks unencapsulated to me :)
-John
Perl 6 Object Oriented Operators [was: Perl 6 - Cheerleaders?]
On Tue, Oct 30, 2001 at 12:27:32PM +1100, Damian Conway wrote:
($obj1, $obj2)-foo(@args);
Is that merely sugar for:
# errr, $_.foo(@args) ?
$_-foo(@args) foreach($obj1, $obj2);
No. What you showed would be achieved with either a hyperoperation:
($obj1, $obj2)^.foo(@args);
[ ... ]
method foo ( $me, $again : $big, $boy ) {...}
should be able to be called via either of:
foo $obj1, $obj2 : @args;
or:
($obj1, $obj2).foo(@args);
This stuff brings to mind all sorts of questions:
* If foo() is declared as above, what values do $me and $again have when
the method is called as $obj.foo(@args);? Is $again undef?
* What happens when foo is declared as method foo ($a: *@_) { ... }
and called as foo $a, $b: @args;? Is $b ignored?
* Would foo $a, $b ^: @args work as ($a,$b)^.foo(@args)?
* Would (($o1,$o2),($o3,$o4))^.foo(@args); be the same as
($o1,$o2).foo(@args); ($o3,$o4).foo(@args); ?
* method foo ($a, $b: *@_) { ... }; foo $o1, $o2: @args; seems like a
binding that doesn't mention :=. i.e., ($a,$b) := ($o1,$o2); Will
there be other hidden uses of the := operator?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Perl 6 Object Oriented Operators [was: Perl 6 - Cheerleaders?]
method foo ( $me, $again : $big, $boy ) {...}
should be able to be called via either of:
foo $obj1, $obj2 : @args;
or:
($obj1, $obj2).foo(@args);
This stuff brings to mind all sorts of questions:
* If foo() is declared as above, what values do $me and $again have when
the method is called as $obj.foo(@args);? Is $again undef?
I would assume it's an error. foo() expects two arguments before the
(implicit) colon, but you gave it only one.
* What happens when foo is declared as method foo ($a: *@_) { ... }
and called as foo $a, $b: @args;? Is $b ignored?
Error. Expected one invocant but found two.
* Would foo $a, $b ^: @args work as ($a,$b)^.foo(@args)?
No. The ^ is on the method call, not on the colon.
BTW, colon isn't an operator (it's a separator), so it can't be hyped.
* Would (($o1,$o2),($o3,$o4))^.foo(@args); be the same as
($o1,$o2).foo(@args); ($o3,$o4).foo(@args); ?
Almost. It would actually be the same as:
( ($o1,$o2).foo(@args), ($o3,$o4).foo(@args) )
though the difference is trivial in a void context.
* method foo ($a, $b: *@_) { ... }; foo $o1, $o2: @args; seems like a
binding that doesn't mention :=. i.e., ($a,$b) := ($o1,$o2);
*All* argument passing to method and subroutine calls is done via
binding (even in Perl 5). Read back over my posts and you'll see that
I always express argument passing in terms like: the first argument
is bound to the $x parameter.
^
Will there be other hidden uses of the := operator?
The other implicit binding is also the same as in Perl 5.
Namely: the iteration variable (or $_) in a Cforeach.
Damian
RE: Perl 6 Object Oriented Operators [was: Perl 6 - Cheerleaders?]
Damian Conway: # BTW, colon isn't an operator (it's a separator), so it can't be hyped. What do you mean? We can hype the colon all we want! :^) --Brent Dax [EMAIL PROTECTED] Configure pumpking for Perl 6 When I take action, Im not going to fire a $2 million missile at a $10 empty tent and hit a camel in the butt. --Dubya
Re: Perl 6 - Cheerleaders?
BD == Brent Dax [EMAIL PROTECTED] writes:
BD Uri Guttman:
BD # DC class Demo {
BD # DC my $foo;
BD # DC my $bar;
BD #
BD # DC method INIT ( $fooval, $barval) {
BD # DC $foo = $fooval;
BD # DC $bar = $barval;
BD # DC }
BD #
BD # DC my $demo = Demo-new(bar='sheep', foo='fighter');
BD method INIT($foo is outer, $bar is outer) {}
BD #outer means don't declare a new one--use the one
BD # that already exists in the 'outer' scope
BD # ('extern' is another possible name)
BD or something like that?
but that doesn't bind to the strings 'bar' and 'foo' in the call
Demo-new(). there needs to be some form of keyword binding unless you
use positional params. as i said i recall something damian mentioned
somewhere about supporting both positional and named params. the syntax
shown above just doesn't do either correctly IMO. this will be worked
out by the usual gang soon enough.
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Perl 6 - Cheerleaders?
On Mon, 29 Oct 2001 11:03:33 +1100 (EST)
Damian Conway [EMAIL PROTECTED] wrote:
The Real Damian is the Damian inside each of us.
You need to get in touch with your *own* inner Damian.
SETTING: Trendy bar.
DC: Hey, beautiful, how's it going? Say, do you have a little Damian in
you?
GIRL: No, I don't.
DC: Well, would you like to?
On an on-topic note ... are there any plans in Perl 6 for specifying
OO - RDBMS mapping in the class { } construct? Another way to look at
this would be adding arbitrary fine grained type constraints to
attributes, and then tools can be written which examine these constraints
and produce RDBMS schemas.
It would be a bit like Class::Contract merged with Class::Tangram, but if
Class::Contract is going into the core then it's a feature I'd like to
see...
Sam.
Re: Perl 6 - Cheerleaders?
On Mon, Oct 29, 2001 at 11:03:33AM +1100, Damian Conway wrote:
Brent asked:
I assume we're going to recycle 'my' and 'our' to be 'instance' and
'class'--is that correct?
That's what I'm proposing.
This seems wise. Very Perlish.
If it's an outer-scope lexical, use Ccaller-{MY}
Ok, I'm all over the nice new features of Perl6, but darnit,
upvar is one of the primary reasons that TCL is unusable. Please,
let's not soften the walls of lexical scope. They're there for a
reason.
If I ever read documentation to the effect:
=head2 CALLBACKS
All callbacks have access to the state of the event
handler through the lexical variables $state and
%state_data in the caller's namespace.
I will defenestrate the offending programmer. Is there any GOOD reason
to want this? Will we ever WANT to write:
class Foo {
my $bar;
sub fu {
my $bar;
}
}
Is that something to encourage? Is accessing a method caller's namepsace
desirable? That seems as bad as the caller accessing the member
variables.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Mon, Oct 29, 2001 at 11:57:47AM +1100, Damian Conway wrote:
AJS How would this play with constants?
class Demo {
my $threshold is const = 100;
Hmm... is a my const the same as an our const? If so, does this mean
that there will be no such thing as a C++-style const (constant per
instance)?
I'm thinking something like:
class Demo {
my $id is immutable;
method INIT ($demo_id is initializer ($id)) {}
is initializer is rather long, but you get the idea.
Does this help Perl at all? Maybe. It depends on the implementation
of the core. Does it help Perl programmers? I think so. It's nice
to be able to state with surety that a member will not be changed
by any of the methods.
Seriously, it would be nice to have a BNF somewhere, even if it changed
every day, and had a few alternates sections... I'd be interested
in starting this if no one else has their heart set on doing it. Perhaps
I could get it into a CVS archive so that we can all edit it on our
own branches.
I'm not proposing anything super-useful for actually cranking out
Perl6's perly.y, but just a high-level view of the operators and
essential syntax.
I'm planning to write a Perl6::Classes module as a proof-of-concept to
accompany my proposal.
Ok. I'll keep an eye out for this, and meanwhile I'll dust off my
BNF skills.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
%MY:: (was Re: Perl 6 - Cheerleaders?)
Aaron Sherman [EMAIL PROTECTED] wrote:
If it's an outer-scope lexical, use Ccaller-{MY}
Ok, I'm all over the nice new features of Perl6, but darnit,
upvar is one of the primary reasons that TCL is unusable. Please,
let's not soften the walls of lexical scope. They're there for a
reason.
The main motivating factor for %MY:: is so that 'use Foo' allows Foo
to modify the lexical scope of its invoker, as opposed to Perl 5 where
it has to modify the whole package to import symbols.
Clearly this is a Good Thing.
As to whether other uses of %MY:: are Good Things, see previous discussions
ad nauseum on -internals and -language.
Re: %MY:: (was Re: Perl 6 - Cheerleaders?)
On Mon, Oct 29, 2001 at 03:03:58PM +, Dave Mitchell wrote: As to whether other uses of %MY:: are Good Things, see previous discussions ad nauseum on -internals and -language. Ok, sorry. I didn't mean to resurect an old, tired thread. I'm sure clear heads will prevail and some precaution will be available. -- Aaron Sherman [EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint: www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF Write your letters in the sand for the day I'll take your hand In the land that our grandchildren knew. -Queen/_'39_
RE: Perl 6 - Cheerleaders?
From: Sam Vilain [mailto:[EMAIL PROTECTED]] It would be a bit like Class::Contract merged with Class::Tangram, but if Class::Contract is going into the core then it's a feature I'd like to see... I'd like to see Class::Contract play nicely with Class::Tangram, Class::Multimethods, etc. But Class::Contract as-is has a bit too much rolled into it, and doesn't always play nicely with others. It needs to be broken out and rebuilt upon shared building block classes, like some of Damian's newer contributions: Hook::LexWrap, Attribute::Handlers, NEXT, etc. As the current maintainer of Class::Contract, I'd love to hear your ideas and better yet see some code to help Class::Contract work better with Class::Tangram.
Re: Perl 6 - Cheerleaders?
[EMAIL PROTECTED] writes:
: Aaron wrote:
:
: Several questions come up.
:
:* If $.foo is like the Perl5 $self-{foo},
:
: Except (as I'm sure you know) that Perl 6 class instantiations aren't
: hashes, and their attributes aren't hash entries.
Nevertheless, *using* one as a hash might work, as long as you don't
try to create non-existent accessor methods.
:* Is foo in this context an auto-quoted key, or an
: actual entry in the namespace? I ask because I'm
: trying to find out how this interacts with Perl's
: (un)reserved words.
:
:print $.if 1; # comes to mind
:
: This is:
:
: print ${'.if'} 1; # syntax error
:
: not:
:
: print $. if 1;
Since $. is going away in favor of a filehandle attribute, we can treat
$. as a prefix just like $# is currently. So $.if should be fine.
:* Do you always have to use parens now for method invocation?
:
: No.
Except when interpolating a method call.
: I'm quite curious to see what the initialization syntax will be like.
:
: class Demo {
: my $foo;
: my $bar;
:
: method INIT ( $fooval, $barval) {
: $foo = $fooval;
: $bar = $barval;
: }
:
: method foo is lvalue {
: return $foo;
: }
: }
Ick. I don't want to lose the dots that visually distinguish instance
variables from ordinary lexicals, and simultaneously render the extra
bracketing and indentation unnecessary. I'd write the above as:
class Demo;
my $.foo is public;
my $.bar;
method INIT ($fooval, $barval) {
$.foo = $fooval;
$.bar = $barval;
}
If you want to limit the scope, you can always bracket around the whole
thing, just as with the package declaration. And I'd like class and
module to just be variants of the package keyword. That makes them
easier to teach.
Larry
Re: Perl 6 - Cheerleaders?
[EMAIL PROTECTED] writes:
: On 10/28/01 7:57 PM, Damian Conway wrote:
:method foo is lvalue {
:return $foo;
:
: Any word on automagical creation of these suckers?
Yes, certainly. Didn't I say that already?
Larry
Re: Perl 6 - Cheerleaders?
On 10/29/01 4:38 PM, Larry Wall wrote:
: I'm quite curious to see what the initialization syntax will be like.
:
: class Demo {
: my $foo;
: my $bar;
:
: method INIT ( $fooval, $barval) {
: $foo = $fooval;
: $bar = $barval;
: }
:
: method foo is lvalue {
: return $foo;
: }
: }
Ick. I don't want to lose the dots that visually distinguish instance
variables from ordinary lexicals, and simultaneously render the extra
bracketing and indentation unnecessary.
Yeah, that Java-like nesting must have slipped by me earlier. (Maybe I just
read it as Java? ;) I definitely like this better:
class Demo;
my $.foo is public;
my $.bar;
method INIT ($fooval, $barval)
{
$.foo = $fooval;
$.bar = $barval;
}
(sorry, couldn't help fixing the braces... ;)
-John
Re: Perl 6 - Cheerleaders?
On 10/29/01 4:39 PM, Larry Wall wrote:
[EMAIL PROTECTED] writes:
: On 10/28/01 7:57 PM, Damian Conway wrote:
:method foo is lvalue {
:return $foo;
:
: Any word on automagical creation of these suckers?
Yes, certainly. Didn't I say that already?
You say a lot of things... :)
(Can I pre-order the Perl 6 Camel or what? ;)
-John
Re: Perl 6 - Cheerleaders?
Brent Dax writes:
: Are we still gonna be able to pick what we call the current instance?
: From previous programming languages, I'm a lot more comfortable with $me
: or $this than $self. (Yeah, it's a little thing, but it's something I
: *liked* about Perl 5's OO--it showed how you had flexibility. And I
: *like* that flexibility, dammit!) Perhaps:
:
: method bar {
: ...
: }
:
: will assume $self, but:
:
: method bar($me : *@_) {
: ...
: }
:
: will use $me instead.
That is the approach I currently favor. (Though I'd probably leave
out the space in front of the colon.) And it has the advantage that
$me is automatically assumed to be read only.
I think the other kind of proposal:
method bar (*@_) {
my $me is mumble;
is just going back to the sort of inside-out declarations we're trying
to get away from. I'd even prefer a pragma over that.
Larry
Re: Perl 6 - Cheerleaders?
[EMAIL PROTECTED] writes:
:method INIT ($fooval, $barval)
:{
: $.foo = $fooval;
: $.bar = $barval;
:}
:
: (sorry, couldn't help fixing the braces... ;)
I don't really care where you put the initial brace, as long as you
outdent the closing brace. My personal brace style does
foo {
...
}
when foo is short enough to fit on one line, but
bar
{
...
}
if bar is going to be be split over multiple lines. So even I would
put the bracket on its own line for this:
method INIT (Dog $fooval is bowwow(3) woof(2) wag(1,2,3),
Cat $barval is ack(0.5) pfft(9) )
{
$.foo = $fooval;
$.bar = $barval;
}
On the other hand, I save a lot of relatively useless whitespace by not
doing that consistently. Of course, if I was paid by the line...
Larry
RE: Perl 6 - Cheerleaders?
Damian Conway:
# Larry revealed:
#
# :method bar($me : *@_) {
# :...
# :}
# :
# : will use $me instead.
#
# That is the approach I currently favor. (Though I'd
# probably leave
# out the space in front of the colon.) And it has the
# advantage that
# $me is automatically assumed to be read only.
#
#
# Okay, so let's clarify:
#
# 1. If you declare a method *with* a colon separator in
# its parameter
# list:
#
# method foo ($self: $foosrc, $foodest, $etc) {...}
#
# then the parameter before the colon is bound to the invocant,
# and the parameters after the colon are bound to the other
# args of the method call.
#
#
# 2. If you declare a method *without* a colon separator in its
# parameter list:
#
# method foo ($foosrc, $foodest, $etc) {...}
#
# then the parameters are bound to the non-invocant
# args of the method call and the invocant itself is
# inaccessible (except implicitly through the unary dot
# operator).
#
#
# 3. If you declare a method *without* any parameter list:
#
# method foo {...}
#
# then the method call arguments (including the invocant?)
# are bound to @_.
What about the case where you want method 'bar' to be called like C
$obj-bar($a, $b: $c, $d) ? It would seem unfair to ban the use of
colon on method calls, or to make you declare a self; perhaps:
method bar($a, $b: $c, $d) {
...
}
That still leaves the case of C $obj-bar($a: $b, $c) . Perhaps:
method bar(: $a: $b, $c)
would work for that?
--Brent Dax
[EMAIL PROTECTED]
Configure pumpking for Perl 6
When I take action, Im not going to fire a $2 million missile at a $10
empty tent and hit a camel in the butt.
--Dubya
Re: Perl 6 - Cheerleaders?
Ick. I don't want to lose the dots that visually distinguish instance
variables from ordinary lexicals, and simultaneously render the extra
bracketing and indentation unnecessary. I'd write the above as:
class Demo;
my $.foo is public;
my $.bar;
method INIT ($fooval, $barval) {
$.foo = $fooval;
$.bar = $barval;
}
If you want to limit the scope, you can always bracket around the whole
thing, just as with the package declaration. And I'd like class and
module to just be variants of the package keyword. That makes them
easier to teach.
Except that you now have to explain why -- unlike an ordinary
my $variable -- the lexical scope of a my $.variable is to the
end of its class, not the end of its block or file.
:-(
Or does the lexical scope of a class extend only to the start of
the next class (unlike a package)? And if so, then which way does
a module work? And does a module or package close the lexical
scope of a class? And vice-versa?
:-(
Damian
Re: Perl 6 - Cheerleaders?
Sam asked:
are there any plans in Perl 6 for specifying
OO - RDBMS mapping in the class { } construct? Another way to look at
this would be adding arbitrary fine grained type constraints to
attributes, and then tools can be written which examine these constraints
and produce RDBMS schemas.
I would imagine that the combination of optional typing and the
ability to define handlers for arbitrary com[ile-time traits would
solve this problem:
class Demo;
use Attributes::RDBMS;
my NUM $.attr1 is key(primary) require(0);
my STR $.attr is key;
# etc.
Damian
Re: Perl 6 - Cheerleaders?
($obj1, $obj2)-foo(@args);
Is that merely sugar for:
# errr, $_.foo(@args) ?
$_-foo(@args) foreach($obj1, $obj2);
No. What you showed would be achieved with either a hyperoperation:
($obj1, $obj2)^.foo(@args);
or a superposition:
any($obj1, $obj2).foo(@args);
What I was proposing was that, since:
method foo ( $me : $big, $boy ) {...}
can be called via either of:
foo $obj: @args;
or:
$obj.foo(@args);
then, by analogy:
method foo ( $me, $again : $big, $boy ) {...}
should be able to be called via either of:
foo $obj1, $obj2 : @args;
or:
($obj1, $obj2).foo(@args);
or is there something more interesting going on?
The latter. :-)
Maybe we need a method call hyperoperator. I didn't just say that.
Since we already have a method call (non-hyper)operator, and since the
hyper-prefix will hype *any* operator, we already have a method
call hyperoperator:
# method call # method hyper-call
$obj.method(@args) -- @objlist^.method(@args)
PS: I'd just like to point out that people gasped in horror when
I presented this idea at YAPC::NA::2001 as part of the
(soon-to-be-released) Klingon binding of Perl. ;-)
I'll add my own, now.
nuch SoH! bIQambogh DaqDaq qaHoH!
DamIan!
Re: Perl 6 - Cheerleaders?
At 12:27 PM 10/30/2001 +1100, Damian Conway wrote: PS: I'd just like to point out that people gasped in horror when I presented this idea at YAPC::NA::2001 as part of the (soon-to-be-released) Klingon binding of Perl. ;-) I'll add my own, now. nuch SoH! bIQambogh DaqDaq qaHoH! The biggest problem with reading mail from Damian is I keep wanting to rot13 the thing.. Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Perl 6 - Cheerleaders?
On 10/29/01 8:44 PM, Dan Sugalski wrote: At 12:27 PM 10/30/2001 +1100, Damian Conway wrote: nuch SoH! bIQambogh DaqDaq qaHoH! The biggest problem with reading mail from Damian is I keep wanting to rot13 the thing.. Whatever filter he's running his thoughts through, I'm pretty sure it's lossy... ;) -John
Re: Perl 6 - Cheerleaders?
Does this mean that the caller of a multimethod has to know he calls a multimethod (as oposed to a regular method). Should not the user of a library spared from such implementation details, however sexy they are? One might well argue the same thing about calling normal subroutines vs methods. Personally, I think you *should* have to be explicit as to whether you're expecting to do single or multiple dispatch, so the compiler can catch those cases where your expectation is at odds with the program's actual semantics. Damian
Re: Perl 6 - Cheerleaders?
John observed: Whatever filter he's running his thoughts through, I'm pretty sure it's lossy... ;) For which mercy you should probably be extremely grateful. ;-) Damian
Re: Perl 6 - Cheerleaders?
DC == Damian Conway [EMAIL PROTECTED] writes:
DC Uri asked:
DC method INIT ( $fooval, $barval) {
where is the binding from the keys below to the INIT params? surely (and
yes, i am calling you shirley) you don't mean that 'bar' is converted or
mapped to $barval? i recall somewhere that there would be a mapping of
'bar's value that can be used or referenced by the INIT method.
DC my $demo = Demo-new(bar='sheep', foo='fighter');
DC My bad. Should of course have been:
DCmy $demo = Demo-new(barval='sheep', fooval='fighter');
that clears it up. so the key/value named params get converted to scalar
args in INIT with the same name. is this in any of the current exegeses?
or will sub calls be covered in the apocalyptic future?
uri
--
Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com
SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com
Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Perl 6 - Cheerleaders?
Uri wrote: that clears it up. so the key/value named params get converted to scalar args in INIT with the same name. is this in any of the current exegeses? or will sub calls be covered in the apocalyptic future? A3/E3 covered named arguments. The only additional bit here is that arguments (named of otherwise) given to the standard Cnew constructoir are passed on to the standard INIT initializer. Damian
Re: Perl 6 - Cheerleaders?
DC == Damian Conway [EMAIL PROTECTED] writes: DC Uri wrote: that clears it up. so the key/value named params get converted to scalar args in INIT with the same name. is this in any of the current exegeses? or will sub calls be covered in the apocalyptic future? DC A3/E3 covered named arguments. The only additional bit here is DC that arguments (named of otherwise) given to the standard Cnew DC constructoir are passed on to the standard INIT initializer. but from this thread it looks like you and larry are still hammering out the details. :) maybe a revision of A3/E3 will be in the offing (like larry's retraction of dropping ). uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
Re: Perl 6 - Cheerleaders?
On Tue, Oct 30, 2001 at 09:59:49AM +1100, Damian Conway wrote:
class Demo {
my $threshold is const = 100;
Hmm... is a my const the same as an our const?
No. 'my' is per-instance; 'our' is per-class.
But, in terms of constants, it seems to me that there's no
difference. They both have only one value that is assigned
when the module/class is parsed.
class Demo {
my $id is immutable;
method INIT ($demo_id is initializer ($id)) {}
is initializer is rather long, but you get the idea.
I'd do that like so (using Larry's preferred syntax):
[...]
method INIT ($idval) { $.id := $idval }
Hm... that looks to me like a regular :=; is it?
If so, what good is is const if you can override it with
a :=? Am I missing something?
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
but from this thread it looks like you and larry are still hammering out the details. :) maybe a revision of A3/E3 will be in the offing (like larry's retraction of dropping ). That's entirely possible. The Perl 6 Ministry of Truth is forever on the look-out for Revisionist Heresies! ;-) Damian
Re: Perl 6 - Cheerleaders?
Aaron pointed out:
But, in terms of constants, it seems to me that there's no
difference. They both have only one value that is assigned
when the module/class is parsed.
Well, in *practice* there's no difference, but in their mystical essences,
they're completely different. ;-)
I'd do that like so (using Larry's preferred syntax):
[...]
method INIT ($idval) { $.id := $idval }
Hm... that looks to me like a regular :=; is it?
Yep.
If so, what good is is const if you can override it with
a :=? Am I missing something?
That's a binding, not an assignment.
Cis const means: Once declared cannot be *assigned* to.
But that doesn't mean one can't *bind* a new value to the variable
(which would retain its Cconst-induced unassignability after the binding).
Consider the following Perl 5:
# CREATE CONSTANT
*constant = \7;
print $constant\n;
# TRY TO ASSIGN (THROWS EXCEPTION)
eval { $constant = -7 } or print $@;
print $constant\n;
# TRY TO REBIND (WORKS FINE)
eval { *constant = \-7) } or print $@;
print $constant\n;
The analogy in Perl 6 would be:
# CREATE CONSTANT
my $constant is const = 7;
print $constant\n;
# TRY TO ASSIGN (THROWS EXCEPTION)
try { $constant = -7 } catch { print $! }
print $constant\n;
# TRY TO REBIND (WORKS FINE)
try { $constant := -7) } catch { print $! }
print $constant\n;
Damian
RE: Perl 6 - Cheerleaders?
Brent asked:
# Well, I'm not a Damian, but I play one on perl6-language. ;-)
Well, then, where's a *real* Damian? :^)
The Real Damian is the Damian inside each of us.
You need to get in touch with your *own* inner Damian.
;-)
I assume we're going to recycle 'my' and 'our' to be 'instance' and
'class'--is that correct?
That's what I'm proposing.
Will that be lvalue or rw? I could see it being rw, to keep the number
of intrinsic properties to a minimum, and since it's a nice analogy to
rw parameters. (Plus we might want to reserve lvalue for more magical
lvalue tricks--sort of a poor man's tie().)
Still to be decided. Most folks I've talked to (and that's quite a few folks)
like Cis rw for parameters, but loathe it for return values. We'll see.
What if we have an instance variable $foo and a global $foo, and we want
to access the global?
If it's a package variable, prefix it with it's package name
(actually, s/package/module/g in Perl 6, but I didn't want to confuse the
issue further)
If it's a true global, use $*foo (a la Apocalypse 2)
If it's an outer-scope lexical, use Ccaller-{MY} or else rebind it
before the class declaration:
my $foo;
$bar := $foo;
class Whatever {
my $foo;
method baz {
return $fooif $bar;
#^ ^
#| |
# attribute $foo outer lexical $foo
}
}
Are we still gonna be able to pick what we call the current instance?
I would hope so.
I favour the ability to write:
method actor {
my $me is invocant;
...
}
All these Star Trek references are threatening to make my warp core
breach... :^)
Too much information.
;-)
Damian
Re: Perl 6 - Cheerleaders?
Damian Conway [EMAIL PROTECTED] writes: Brent told us: All these Star Trek references are threatening to make my warp core breach... :^) Too much information. Look, I'm sorry, okay? I only finished up the article with a Trek reference because, whilst I could see Larry as Giles, I was having a hard time envisioning Damian as Willow, Nat as Buffy and Dan as Xander. And the fallback plan of doing it all in the style of Jane Austen was just Too Hard. Besides, when you're writing an article saying 'This is really cool', a voice that's heavy on satirical irony doesn't quite work. -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
RE: Perl 6 - Cheerleaders?
Aaron wrote:
Several questions come up.
* If $.foo is like the Perl5 $self-{foo},
Except (as I'm sure you know) that Perl 6 class instantiations aren't
hashes, and their attributes aren't hash entries.
how do I do the Perl5 $self-foo?
.foo()
* Is foo in this context an auto-quoted key, or an
actual entry in the namespace? I ask because I'm
trying to find out how this interacts with Perl's
(un)reserved words.
print $.if 1; # comes to mind
This is:
print ${'.if'} 1; # syntax error
not:
print $. if 1;
* Do you always have to use parens now for method invocation?
No.
class Demo {
my $foo;
method foo is lvalue {
return $foo;
}
}
Hmmm... I'm trying really hard to get my head 'round this.
So, a class is a scope which creates a new closure every time it's
instantiated?
That's the effect, yes. Though probably not the implementation.
I prefer to think of it like this: a class is a template for the lexical
scope in which each object lives and moves and has its being.
This is intriguing. Certainly it removes any question
of unauthorized member access.
Yep! ;-)
I'm quite curious to see what the initialization syntax will be like.
class Demo {
my $foo;
my $bar;
method INIT ( $fooval, $barval) {
$foo = $fooval;
$bar = $barval;
}
method foo is lvalue {
return $foo;
}
}
my $demo = Demo-new(bar='sheep', foo='fighter');
Will there be a special initialization method, or will we have something
like a BEGIN block inside the class?
The former. The name is TBA though, since it's probably too confusing
to have INIT blocks and INIT initializers with no real relationship
between them.
How would this play with constants?
class Demo {
my $threshold is const = 100;
...
}
Seriously, it would be nice to have a BNF somewhere, even if it changed
every day, and had a few alternates sections... I'd be interested
in starting this if no one else has their heart set on doing it. Perhaps
I could get it into a CVS archive so that we can all edit it on our
own branches.
I'm not proposing anything super-useful for actually cranking out
Perl6's perly.y, but just a high-level view of the operators and
essential syntax.
I'm planning to write a Perl6::Classes module as a proof-of-concept to
accompany my proposal.
Damian
Re: Perl 6 - Cheerleaders?
On 10/28/01 7:03 PM, Damian Conway wrote:
Brent asked:
I assume we're going to recycle 'my' and 'our' to be 'instance' and
'class'--is that correct?
That's what I'm proposing.
So should I start practicing my typos for instance now? Insatance
instancae instance. Mmmm... ;P
I favour the ability to write:
method actor {
my $me is invocant;
...
}
Invocatnt incvocant invocant... ;)
-John
Re: Perl 6 - Cheerleaders?
On 10/28/01 7:57 PM, Damian Conway wrote:
method foo is lvalue {
return $foo;
Any word on automagical creation of these suckers? No, not as a module, but
built-in. I don't think it's too crazy to build *some* sort of sensible
attribute accessor auto-creation in. I know the first thing I'll probably
write is something that auto-creates exactly what's shown above, and then
I'm (kind of) back into a small slice of Perl 5 oo.
I guess what I'm really hoping for in Perl 6 is to finally give up my
super-simple object base class that does cascading initialization (check)
and simple attribute accessor creation (???) when necessary.
-John
Re: Perl 6 - Cheerleaders?
On Sun, Oct 28, 2001 at 08:36:31PM -0500, John Siracusa wrote:
On 10/28/01 7:57 PM, Damian Conway wrote:
method foo is lvalue {
return $foo;
Any word on automagical creation of these suckers? No, not as a module, but
built-in.
They're called Slots and god I hope so.
--
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern/
Perl6 Quality Assurance [EMAIL PROTECTED] Kwalitee Is Job One
Re: Perl 6 - Cheerleaders?
On Thu, 25 Oct 2001 16:53:46 -0500, Garrett Goebel wrote: Piers Cawley has written a nice article entitled: Perl 6 : Not Just For Damians. http://www.perl.com/pub/a/2001/10/23/damians.html I just hope that you don't really have to insert that many blank lines in your code just to make it compile. -- Bart.
Re: Perl 6 - Cheerleaders?
Uri Guttman [EMAIL PROTECTED] writes: GG == Garrett Goebel [EMAIL PROTECTED] writes: GG Piers Cawley has written a nice article entitled: Perl 6 : Not GG Just For Damians. GG If the hair on the back of your neck rises when thinking about GG Perl 6, or even if it doesn't... give it a read. GG http://www.perl.com/pub/a/2001/10/23/damians.html please, just make sure ensign cawley doesn't wear a red shirt. Actually, I'm more of a Next Generation kind of guy... -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Perl 6 - Cheerleaders?
Bart Lateur [EMAIL PROTECTED] writes: On Thu, 25 Oct 2001 16:53:46 -0500, Garrett Goebel wrote: Piers Cawley has written a nice article entitled: Perl 6 : Not Just For Damians. http://www.perl.com/pub/a/2001/10/23/damians.html I just hope that you don't really have to insert that many blank lines in your code just to make it compile. Hmm... how did that happen. Simon? -- Piers It is a truth universally acknowledged that a language in possession of a rich syntax must be in need of a rewrite. -- Jane Austen?
Re: Perl 6 - Cheerleaders?
On Thu, Oct 25, 2001 at 04:53:46PM -0500, Garrett Goebel wrote:
Piers Cawley has written a nice article entitled: Perl 6 : Not Just For
Damians.
I had missed what unary . really did, and this explained it to me. I'm
now much more excited about it as a with-like operator.
It does make me think, though... Would it make sense to have an
accessor operator? For example, in Perl5 I would do this:
sub foo {
my $self = shift;
my $old = $self-{foo};
# So $obj-foo(undef) will work
if (@_) {
$self-{foo} = shift @_;
}
return $old;
}
In Perl6 with the unary ., that becomes:
sub .foo (*@args) {
my $old = $.{foo};
# So $obj.foo(undef) will work
$.{foo} = shift @args if @args;
return $old;
}
So, since this is likely to be fairly common, could we perhaps have
a shortcut?
sub .{foo} () {}
Of course, this is the simple case. In reality, the transformation
would be:
sub .{NAME} () BLOCK
which becomes
sub .NAME (*@args) {
BLOCK
my $old = $.{NAME};
$.{foo} = shift @args if @args;
return $old;
}
The syntax might not be wise. I dunno how I feel about YAUB
(Yet Another Use of Braces). Perhaps some syntax like:
accessor .NAME () BLOCK
But the .{method} syntax does seem to be a very ovious meaning, given
what .{NAME} is going to mean inside of the method.
Then again, we could call it all quits and come up with a naming
convention that allows some members to be automatically exported
as methods, and others to be withheld.
--
Aaron Sherman
[EMAIL PROTECTED] finger [EMAIL PROTECTED] for GPG info. Fingerprint:
www.ajs.com/~ajs6DC1 F67A B9FB 2FBA D04C 619E FC35 5713 2676 CEAF
Write your letters in the sand for the day I'll take your hand
In the land that our grandchildren knew. -Queen/_'39_
Re: Perl 6 - Cheerleaders?
On Fri, Oct 26, 2001 at 01:13:42PM -0400, Aaron Sherman wrote:
It does make me think, though... Would it make sense to have an
accessor operator? For example, in Perl5 I would do this:
sub foo {
my $self = shift;
my $old = $self-{foo};
# So $obj-foo(undef) will work
if (@_) {
$self-{foo} = shift @_;
}
return $old;
}
In Perl6 with the unary ., that becomes:
sub .foo (*@args) {
my $old = $.{foo};
# So $obj.foo(undef) will work
$.{foo} = shift @args if @args;
return $old;
}
Actually, I think it becomes:
sub foo is method {
my $old = .foo;
.foo = shift if @_;
return $old;
}
But, I could be wrong. Any Damians care to enlighten? :-)
So, since this is likely to be fairly common, could we perhaps have
a shortcut?
I'm not so sure that a) we need short-cut and b) that one doesn't
already fall out of existing er, proposed language features.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: Perl 6 - Cheerleaders?
Jonathan Scott Duff [EMAIL PROTECTED] writes:
On Fri, Oct 26, 2001 at 01:13:42PM -0400, Aaron Sherman wrote:
It does make me think, though... Would it make sense to have an
accessor operator? For example, in Perl5 I would do this:
sub foo {
my $self = shift;
my $old = $self-{foo};
# So $obj-foo(undef) will work
if (@_) {
$self-{foo} = shift @_;
}
return $old;
}
In Perl6 with the unary ., that becomes:
sub .foo (*@args) {
my $old = $.{foo};
# So $obj.foo(undef) will work
$.{foo} = shift @args if @args;
return $old;
}
Actually, I think it becomes:
sub foo is method {
my $old = .foo;
.foo = shift if @_;
return $old;
}
But, I could be wrong. Any Damians care to enlighten? :-)
Perl 6 Perl 5
my $old = .foo my $old = $self-foo;
my $old = $.foo Um... ah... It's accessing an instance
variable. Which Perl 5 doesn't have.
well, you can mock it up with:
Note that this is a variable that is
inaccessible to anything but the object's
methods...
--
Piers
It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite.
-- Jane Austen?
Re: Perl 6 - Cheerleaders?
On Fri, Oct 26, 2001 at 03:28:57PM -0700, Brent Dax wrote:
What if we have an instance variable $foo and a global $foo, and we want
to access the global?
Do you mean if we've hidden a lexical of the same name in the same
scope? I seem to recall something related to %MY that would let you
access outer scopes, but I don't remember the details. Perhaps I'm
thinking of the discussion regarding modifying the callers environment.
Wait for the OOP Apocalypse/Exegesis.
Are we still gonna be able to pick what we call the current instance?
That's a good question. With the implicit-self of unary dot, I don't
see how we get at the object directly. Perhaps it will be something like
this:
method foo {
my $me is self;
$me.blah(); # same as .blah();
}
I don't know. Wait for the OOP Apocalypse/Exegesis :-)
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Perl 6 - Cheerleaders?
Piers Cawley has written a nice article entitled: Perl 6 : Not Just For Damians. If the hair on the back of your neck rises when thinking about Perl 6, or even if it doesn't... give it a read. http://www.perl.com/pub/a/2001/10/23/damians.html
Re: Perl 6 - Cheerleaders?
GG == Garrett Goebel [EMAIL PROTECTED] writes: GG Piers Cawley has written a nice article entitled: Perl 6 : Not GG Just For Damians. GG If the hair on the back of your neck rises when thinking about GG Perl 6, or even if it doesn't... give it a read. GG http://www.perl.com/pub/a/2001/10/23/damians.html please, just make sure ensign cawley doesn't wear a red shirt. :-) uri -- Uri Guttman - [EMAIL PROTECTED] -- http://www.sysarch.com SYStems ARCHitecture and Stem Development -- http://www.stemsystems.com Search or Offer Perl Jobs -- http://jobs.perl.org
