Properties & Methods
Piers Cawley
> Another one of my little annonyances in the current state of P6 is how
> run-time properties are accessed. Accessing properties as methods is
> pretty, but I see it as potentially dangerous.
>
> Adding a new method to a class that happens to be the same as
> somebody's property would be lucky to get some kind of signature
> error. In the worst case (and unfortunately, probably the common one)
> the method will have only internal side-effects, and it will be being
> called at apparently random times.
class Foo {
...
my method only_internal_side_effects { ... }
}
Now, when something outside Foo's class hierarchy calls
$a_foo.only_internal_side_effects it would only see the property, but
when something inside the hierarchy calls it it will see the method
(which is definitely the right thing; it's unlikely to know about the
clashing property).
> Ick.
>
> I think it'd be better to include some kind of "property hash" in
> Object, or have a keyword for checking properties.
I thought we had that already, just as an option. This is one of those
things I can argue both ways I think. Having properties that look like
methods can be really useful and also rather risky. Question is, does
the usefulness outweigh the riskiness?
> Also, junctions have this problem. Apparently a junction only
> distributes a method call if the method isn't in the Junction class
> itself. Consider this:
>
> $junction.$foo();
>
> Depending on the I<run time> value of C<$foo>, the junction's method
> would be called or its junctends' methods. That's not right.
>
> For this one, I don't think it would be too bad to have a global sub
> C<states> that takes a junction as its argument. That removes the
> spooky intercepting delegation that the method way imposes.
Doesn't need to be a global sub, can be a method on Object:
class Object {
method eigenstates { return $_ }
}
'states' is too useful a methodname to use in this fashion I
think. 'eigenstates' is almost certainly wrong too...
--
Piers
Luke Palmer
> > Adding a new method to a class that happens to be the same as
> > somebody's property would be lucky to get some kind of signature
> > error. In the worst case (and unfortunately, probably the common one)
> > the method will have only internal side-effects, and it will be being
> > called at apparently random times.
>
> class Foo {
> ...
>
> my method only_internal_side_effects { ... }
> }
>
> Now, when something outside Foo's class hierarchy calls
> $a_foo.only_internal_side_effects it would only see the property, but
> when something inside the hierarchy calls it it will see the method
> (which is definitely the right thing; it's unlikely to know about the
> clashing property).
I'm talking about adding a method to the class's I<interface>. By
"only internal side-effects" I meant something that would change and
be hard to debug because of it, not something that's only intended for
use by the class.
Maybe it could be a fatal (compile-time, if possible) error to
attribute a property onto a class that already has a method by that
name. It would be safer than the current way (call the method unless
it doesn't exists, then try the property), but it would probably just
be a pain.
I still prefer the property hash solution.
> > Ick.
> >
> > I think it'd be better to include some kind of "property hash" in
> > Object, or have a keyword for checking properties.
>
> I thought we had that already, just as an option. This is one of those
> things I can argue both ways I think. Having properties that look like
> methods can be really useful and also rather risky. Question is, does
> the usefulness outweigh the riskiness?
It doesn't seem like it would be very risky from language-list
examples. But in Real Life I foresee a wealth of frustration.
Especially from my usual generic programming perspective.
Consider:
# Breadth first graph-traversal algorithm
class LinksInteface is Inteface {
method links() returns List {...}
}
sub breadth_first_traversal($root can LinksInterface, &code) {
my @queue is Queue = ($root);
for @queue {
next if .visited;
$_ but= vistited;
code($_);
push @queue: .links;
}
}
That's what I would consider a usual use of properties (but maybe not;
see below[*]). And that would be hell if $root's type defined a
.visited method. Do you see where I'm going though? The method
syntax to access properties is great when you know what types of
variables that your dealing with. But when you're using generic---or
even polymorphic---variables, you can't be sure. And in many
programming cases you are using at least polymorphic variables.
> > Also, junctions have this problem. Apparently a junction only
> > distributes a method call if the method isn't in the Junction class
> > itself. Consider this:
> >
> > $junction.$foo();
> >
> > Depending on the I<run time> value of C<$foo>, the junction's method
> > would be called or its junctends' methods. That's not right.
> >
> > For this one, I don't think it would be too bad to have a global sub
> > C<states> that takes a junction as its argument. That removes the
> > spooky intercepting delegation that the method way imposes.
>
> Doesn't need to be a global sub, can be a method on Object:
>
> class Object {
> method eigenstates { return $_ }
> }
>
> 'states' is too useful a methodname to use in this fashion I
> think. 'eigenstates' is almost certainly wrong too...
This is no solution at all. Whether it is a method on Junction or on
Object doesn't matter. I'm saying that it's evil to call a method on
a junction and get something about the junction back, and call a
different method and get a junction of things about the junctends
back.
But I don't have a lot of experience with programming with
delegation, so I can't really say whether this will be an outstanding
problem.
----
[*] This is not, in fact, a good generic solution. Since the visited
property will hang around the nodes after the traversal has finished,
it will be impossible to do another traversal on the same graph, since
the root node will start out visited.
In this case it would be great to have lexically and dynamically
scoped properties. So:
sub breadth_first_traversal($root can LinksInterface, &code) {
my property visited;
# ...
}
Or something, which would make the visited property a special one that
is only visible in this invocation of the sub. Anybody else who
checks the visited property would see that it isn't set (unless they
had a different visited property).
Maybe properties are variables, independent of what they are attached
to. Then it would be possible to do all the neat scoping stuff we can
do with other variables. You could store references to properties,
and all that good stuff.
=begin gross_speculation
And then maybe they need sigils. Then we could use the dot notation:
sub breadth_first_traversal($root can LinksInterface, &code) {
my ^visited;
# ...
unless $node.^visited
}
(I had a choice of 3 sigils: >, |, and ^)
return 0 but ^true;
=end gross_speculation
Or, we could make them typed scalars:
sub breadth_first_traversal($root can LinksInterface, &code) {
my $visited = new Property;
# ...
unless $node.$visited
}
I really like the scoped property idea, however it might be done.
Luke
Austin Hastings
--- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
>
> In this case it would be great to have lexically and dynamically
> scoped properties. So:
>
> sub breadth_first_traversal($root can LinksInterface, &code) {
> my property visited;
> # ...
> }
>
> Or something, which would make the visited property a special one
> that
> is only visible in this invocation of the sub. Anybody else who
> checks the visited property would see that it isn't set (unless they
> had a different visited property).
>
Earlier on this list someone suggested that the only UML entity not
well-represented in P6 so far is associations. This is evidence for
that -- what is needed here is a way to tie the (relatively permanent)
nodes to a (temporary) external item. Associations would do that.
> Maybe properties are variables, independent of what they are attached
> to. Then it would be possible to do all the neat scoping stuff we
> can do with other variables. You could store references to
> properties, and all that good stuff.
>
> =begin gross_speculation
>
> And then maybe they need sigils. Then we could use the dot notation:
>
> sub breadth_first_traversal($root can LinksInterface, &code) {
> my ^visited;
> # ...
> unless $node.^visited
> }
>
> (I had a choice of 3 sigils: >, |, and ^)
You could use #, I think.
my Property #include is sub { Perl6::Parse(::__interp, shift); }
m4 anyone?
>
> return 0 but ^true;
>
> =end gross_speculation
>
> Or, we could make them typed scalars:
>
> sub breadth_first_traversal($root can LinksInterface, &code) {
> my $visited = new Property;
> # ...
> unless $node.$visited
> }
>
> I really like the scoped property idea, however it might be done.
This *really* points to associations, since they would (obviously) die
when the referenced object went out of scope. (Unless they didn't, in
which case the object.DESTROY method should just automatically break
any associations it has.)
my $visited = new Association(...);
sub breadth_first_traversal($root can LinksInterface, &code) {
my $traversal = new Scalar(1); # Unique traversal id.
if ($root has visited($traversal)) {...}
else {
$visited.relate($root, $traversal);
}
}
This example is kind of weak because it suggests that associations can
be implemented as a "pure" module -- I don't think they can because of
(1) performance; and (2) behavior. I think that association behavior
should be supported by the root of the object tree -- that is, if
associations will be broken by C<DESTROY>ing an object, then we need to
make sure that the object tree does that, right at the top.
=Austin
Dan Sugalski
>In this case it would be great to have lexically and dynamically
>scoped properties. So:
Gah! No! Nononononononono! Have I mentioned I'd rather not?
Lexically and dynamically scoped *methods* I can manage, as that's
just a layered namespace issue, and that's no big deal. Lexically and
dynamically scoped *properties*, though... Yowtch.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jonathan Scott Duff
>
> --- Luke Palmer <fibo...@babylonia.flatirons.org> wrote:
> >
> > In this case it would be great to have lexically and dynamically
> > scoped properties. So:
> >
> > sub breadth_first_traversal($root can LinksInterface, &code) {
> > my property visited;
> > # ...
> > }
> >
> > Or something, which would make the visited property a special one
> > that
> > is only visible in this invocation of the sub. Anybody else who
> > checks the visited property would see that it isn't set (unless they
> > had a different visited property).
> >
>
> Earlier on this list someone suggested that the only UML entity not
> well-represented in P6 so far is associations. This is evidence for
> that -- what is needed here is a way to tie the (relatively permanent)
> nodes to a (temporary) external item. Associations would do that.
Actually, I was thinking that this was a good example of where to NOT
use properties. By extension, I also think this is a good example of
where to not use associations (at least not as some special language
construct)
What's wrong with a simple hash?
sub breadth_first_traversal($root can LinksInterface, &code) {
my @queue is Queue = ($root);
my %visited;
for @queue {
next if %visited{.id};
%vistited{.id}++;
code($_);
push @queue: .links;
}
}
If you want to temporarily attach some piece of data to an object and
have that data destroyed when it's no longer needed, that sounds like
a lexically scoped thing. Whether that thing *really* needs to be
attached to the object, I'm doubtful.
As far as associations go, I view them as akin to a two-way mapping
where you can update one half of the map and get the other half
updated for free. At least that's the most salient feature. Looks
like a hash accomplishes this task quite well here.
-Scott
--
Jonathan Scott Duff
du...@cbi.tamucc.edu
Larry Wall
: At 12:12 AM -0600 4/8/03, Luke Palmer wrote:
: >In this case it would be great to have lexically and dynamically
: >scoped properties. So:
:
: Gah! No! Nononononononono! Have I mentioned I'd rather not?
:
: Lexically and dynamically scoped *methods* I can manage, as that's
: just a layered namespace issue, and that's no big deal. Lexically and
: dynamically scoped *properties*, though... Yowtch.
But what if you just think of the property as a method on a singleton class?
Larry
Dan Sugalski
Then I have to completely rip out the current property system,
property introspection becomes much harder, and the property hash you
mandated doesn't work well any more.
Other than that I can do it... :)
Mark Biggar
Dan Sugalski
Then you find that it doesn't get overridden by methods in the
object's class, as it's supposed to, and that as a method it's not
particularly noteworthy so that when you ask the variable for its
properties hash you don't get it back...
John Williams
> At 11:26 AM -0700 4/8/03, Larry Wall wrote:
> >On Tue, Apr 08, 2003 at 11:01:24AM -0400, Dan Sugalski wrote:
> >: At 12:12 AM -0600 4/8/03, Luke Palmer wrote:
> >: >In this case it would be great to have lexically and dynamically
> >: >scoped properties. So:
> >:
> >: Gah! No! Nononononononono! Have I mentioned I'd rather not?
> >:
> >: Lexically and dynamically scoped *methods* I can manage, as that's
> >: just a layered namespace issue, and that's no big deal. Lexically and
> >: dynamically scoped *properties*, though... Yowtch.
> >
> >But what if you just think of the property as a method on a singleton class?
>
> Then I have to completely rip out the current property system,
> property introspection becomes much harder, and the property hash you
> mandated doesn't work well any more.
What the heck, I'll doubt Dan too...
We have a property hash, and dynamic hash elements. Doesn't that give us
dynamic properties?
No lexical hash elements. bummer.
~ John Williams
Larry Wall
: At 11:26 AM -0700 4/8/03, Larry Wall wrote:
: >On Tue, Apr 08, 2003 at 11:01:24AM -0400, Dan Sugalski wrote:
: >: At 12:12 AM -0600 4/8/03, Luke Palmer wrote:
: >: >In this case it would be great to have lexically and dynamically
: >: >scoped properties. So:
: >:
: >: Gah! No! Nononononononono! Have I mentioned I'd rather not?
: >:
: >: Lexically and dynamically scoped *methods* I can manage, as that's
: >: just a layered namespace issue, and that's no big deal. Lexically and
: >: dynamically scoped *properties*, though... Yowtch.
: >
: >But what if you just think of the property as a method on a singleton
: >class?
:
: Then I have to completely rip out the current property system,
: property introspection becomes much harder, and the property hash you
: mandated doesn't work well any more.
What if the property hash by definition includes the names of all
public methods that are rw and argumentless? Then we have the
delightful benefit that a method definition can be inserted to turn
a passive property into an active one without changing the source
code that calls it. If a class wants to fudge its definition of
"true", it can...
Larry
Luke Palmer
> : At 11:26 AM -0700 4/8/03, Larry Wall wrote:
> : >On Tue, Apr 08, 2003 at 11:01:24AM -0400, Dan Sugalski wrote:
> : >: At 12:12 AM -0600 4/8/03, Luke Palmer wrote:
> : >: >In this case it would be great to have lexically and dynamically
> : >: >scoped properties. So:
> : >:
> : >: Gah! No! Nononononononono! Have I mentioned I'd rather not?
> : >:
> : >: Lexically and dynamically scoped *methods* I can manage, as that's
> : >: just a layered namespace issue, and that's no big deal. Lexically and
> : >: dynamically scoped *properties*, though... Yowtch.
> : >
> : >But what if you just think of the property as a method on a singleton
> : >class?
> :
> : Then I have to completely rip out the current property system,
> : property introspection becomes much harder, and the property hash you
> : mandated doesn't work well any more.
>
> What if the property hash by definition includes the names of all
> public methods that are rw and argumentless?
I'm starting to almost completely dislike this.
What if lexical properties don't show up in the property hash, much as
lexical variables don't show up in the package symbol table. What
properties a sub has assigned some object isn't really anybody else's
business anyway. There's the advantage of being able to clean up a
property after there's no references to it that aren't on a variable.
But the analogy breaks down at %MY.
And again, dynamically scoped properties are a different kind of
bear.
> Then we have the delightful benefit that a method definition can be
> inserted to turn a passive property into an active one without
> changing the source code that calls it. If a class wants to fudge
> its definition of "true", it can...
Hmm, I'd hate to be the generic programmer handling classes like that.
But I guess the idea is that I wouldn't... they'd inflict whatever
misfortune became of that upon themselves. That's really The Perl
Way, come to think of it. 'Nuff rope to hang yourself with. Right.
Luke
Luke Palmer
> want that? (Case in specific point: your breadth-first-traverse routine
> earlier would suddenly acquire a funny bug if the code in question enclosed
> one or more of the nodes while they were tagged as C<visited>, no?)
Um, no. That's the whole point of lexically scoped properties. Every
time I do
my $visited = new Property;
I'm making, as it says, a C<new>, distinct property. It may be that I
don't understand where the bug is. Could you explain and exemplify a
bit more?
> Conversely, enclosing lexical properties might have interesting behavior,
> much the way that enclosing lexical variables does. But making lexical
> properties a "risk" because of the closure behavior means that they're
> suddenly prohibited in cases like your example.
Again, I don't understand.
Luke
Austin Hastings
What about closures? If I enclose a property, that property won't die. Do we
want that? (Case in specific point: your breadth-first-traverse routine
earlier would suddenly acquire a funny bug if the code in question enclosed
one or more of the nodes while they were tagged as C<visited>, no?)
Conversely, enclosing lexical properties might have interesting behavior,
much the way that enclosing lexical variables does. But making lexical
properties a "risk" because of the closure behavior means that they're
suddenly prohibited in cases like your example.
>
> > Then we have the delightful benefit that a method definition can be
> > inserted to turn a passive property into an active one without
> > changing the source code that calls it. If a class wants to fudge
> > its definition of "true", it can...
>
> Hmm, I'd hate to be the generic programmer handling classes like that.
> But I guess the idea is that I wouldn't... they'd inflict whatever
> misfortune became of that upon themselves. That's really The Perl
> Way, come to think of it. 'Nuff rope to hang yourself with. Right.
Right. "It's your fence."
=Austin
Austin Hastings
> -----Original Message-----
> From: Luke Palmer [mailto:fibo...@babylonia.flatirons.org]
> Sent: Tuesday, April 08, 2003 6:23 PM
> To: Austin_...@Yahoo.com
> Cc: perl6-l...@perl.org
> Subject: Re: Properties & Methods
>
>
> > What about closures? If I enclose a property, that property
> won't die. Do we
> > want that? (Case in specific point: your breadth-first-traverse routine
> > earlier would suddenly acquire a funny bug if the code in
> question enclosed
> > one or more of the nodes while they were tagged as C<visited>, no?)
>
> Um, no. That's the whole point of lexically scoped properties. Every
> time I do
>
> my $visited = new Property;
>
> I'm making, as it says, a C<new>, distinct property. It may be that I
> don't understand where the bug is. Could you explain and exemplify a
> bit more?
You may be making a new property, but how does it access?
die "already visited this node" if $root.visited;
Which visited? The "old" visited is still alive, no? So it's still sitting
in the "visited slot" on this node.
Unless the .visited has to check id's, in which case this thread joins with
MikeL's =:= superthread... :-)
>
> > Conversely, enclosing lexical properties might have interesting
> behavior,
> > much the way that enclosing lexical variables does. But making lexical
> > properties a "risk" because of the closure behavior means that they're
> > suddenly prohibited in cases like your example.
>
> Again, I don't understand.
This rides on the point above.
=Austin
Luke Palmer
> > don't understand where the bug is. Could you explain and exemplify a
> > bit more?
>
> You may be making a new property, but how does it access?
>
> die "already visited this node" if $root.visited;
>
> Which visited? The "old" visited is still alive, no? So it's still sitting
> in the "visited slot" on this node.
Aha, you should read my code examples more.
die "already visited this node" if $root.$visited
It's clear which visited is meant... the one in the current lexical scope.
> Unless the .visited has to check id's, in which case this thread joins with
> MikeL's =:= superthread... :-)
Do you really think I would impose such an awful thing on us innocent
programmers?
Luke
Paul
Speaking of which....
in P5, I always thought this was really wierd:
my %h = ( a => 1, b => 2, c => 3 );
print join " ",%h,"\n";
{ local $h{b} = "foo";
print join " ",%h,"\n";
}
print join " ",%h,"\n";
prints
a 1 b 2 c 3
a 1 b foo c 3
a 1 b 2 c 3
I finally digested that, strange as it was to me that local could work
on one element of a my() set, but not the whole. I do get it now --
explanations are unnecessary.
However, how would you do that in P6?
Is that a temp thing? Is it as simple here as replacing local() with
temp? Or maybe let? (I still don't quite get let, either. :)
__________________________________________________
Do you Yahoo!?
Yahoo! Tax Center - File online, calculators, forms, and more
http://tax.yahoo.com
Luke Palmer
> > No lexical hash elements. bummer.
>
> Speaking of which....
> in P5, I always thought this was really wierd:
>
> my %h = ( a => 1, b => 2, c => 3 );
> print join " ",%h,"\n";
> { local $h{b} = "foo";
> print join " ",%h,"\n";
> }
> print join " ",%h,"\n";
>
> prints
>
> a 1 b 2 c 3
> a 1 b foo c 3
> a 1 b 2 c 3
>
> I finally digested that, strange as it was to me that local could work
> on one element of a my() set, but not the whole. I do get it now --
> explanations are unnecessary.
>
> However, how would you do that in P6?
> Is that a temp thing? Is it as simple here as replacing local() with
> temp? Or maybe let? (I still don't quite get let, either. :)
Yep. s/local/temp/.
C<let> is neat. The output from that if C<let> were involved would
be:
a 1 b 2 c 3
a 1 b foo c 3
a 1 b foo c 3
But the output from this:
my %h = ( a => 1, b => 2, c => 3 );
print join " ",%h,"\n";
{ let $h{b} = "foo";
print join " ",%h,"\n";
fail; # or die or (maybe) throw
}
print join " ",%h,"\n";
would be:
a 1 b 2 c 3
a 1 b foo c 3
a 1 b 2 c 3
That is, C<let> makes its changes permanent only if its scope was
exited successfully. It's implications are incredible when you
consider exception safety (you get strong exception safety basically
for free).
Plus a bunch of other things we haven't thought of yet.
Luke
Austin Hastings
> that I
> > > don't understand where the bug is. Could you explain and
> exemplify a
> > > bit more?
> >
> > You may be making a new property, but how does it access?
> >
> > die "already visited this node" if $root.visited;
> >
> > Which visited? The "old" visited is still alive, no? So it's still
> sitting
> > in the "visited slot" on this node.
>
> Aha, you should read my code examples more.
>
> die "already visited this node" if $root.$visited
>
> It's clear which visited is meant... the one in the current lexical
> scope.
Urk!
So we're doing object access, but the namesearch looks like:
$root.visited -> in lexical scope as property?
-> in object property namespace? (see next; order?)
-> in object method list? (see prev; order?)
-> in class method list? (??)
-> in multi namespace?
-> in package sub namespace?
-> in global sub namespace?
Right?
>
> > Unless the .visited has to check id's, in which case this thread
> joins with
> > MikeL's =:= superthread... :-)
>
> Do you really think I would impose such an awful thing on us innocent
> programmers?
In a heartbeat. ;-)
=Austin
Luke Palmer
>
> So we're doing object access, but the namesearch looks like:
>
> $root.visited -> in lexical scope as property?
> -> in object property namespace? (see next; order?)
> -> in object method list? (see prev; order?)
> -> in class method list? (??)
> -> in multi namespace?
> -> in package sub namespace?
> -> in global sub namespace?
>
>
> Right?
No. One more time:
my $visited = new Property;
# v
die "Already visited" if $root.$visited;
# ^
See that $ after the . ? It's like a dynamic method call, except it
knows it's looking for a property because $visited is a property
object, instead of a method object. It has just as many problems with
closures as dynamic method calls do: none.
Oh, and named methods come before named properties in the lookup list.
And, in light of this explanation, the "lexical scope as property"
shouldn't be there.
Luke
Austin Hastings
> >
> > So we're doing object access, but the namesearch looks like:
> >
> > $root.visited -> in lexical scope as property?
> > -> in object property namespace? (see next; order?)
> > -> in object method list? (see prev; order?)
> > -> in class method list? (??)
> > -> in multi namespace?
> > -> in package sub namespace?
> > -> in global sub namespace?
> >
> >
> > Right?
>
> No. One more time:
>
> my $visited = new Property;
> # v
> die "Already visited" if $root.$visited;
> # ^
>
Argh. This is what I get for corresponding before the sun crosses the
yardarm. You're right. That'll work, and it doesn't have anything to do
with lexical scope. I could just as well create a new property at the
package level, or class level, and hang it on there.
Which is nice, because it effectively gives us a "namespace" constraint
for properties.
Going one step farther, this is probably the way all properties should
be handled by default: assume that any property I<not already declared>
exists at the "basic outer scope" of the using code. (Class, or
Package, by default.)
That means that when my code says:
sub do_stuff($x) {
$x but= fnord;
}
and some other 6PAN code says:
package other;
sub other_sub($x) {
show $fear if $x.fnord;
}
the default P6 behavior will be to interfere with each other.
But if we use $fnord, things work out:
$fnord = new Property;
sub do_stuff($x) {
$x but= $fnord;
}
======
package other;
our $fnord = new Property;
sub other_sub($x) {
show fear if $x.$fnord;
}
(The properties that SHOULD be global can be defined globally. The
properties that want to be added as global can be defined that way. But
the default behavior for properties should be scoped, to avoid
interference.)
> See that $ after the . ? It's like a dynamic method call, except it
> knows it's looking for a property because $visited is a property
> object, instead of a method object. It has just as many problems
> with closures as dynamic method calls do: none.
>
> Oh, and named methods come before named properties in the lookup
> list.
> And, in light of this explanation, the "lexical scope as property"
> shouldn't be there.
Yes.
=Austin
Paul
> > > No lexical hash elements. bummer.
> >
> > Speaking of which....
> > in P5, I always thought this was really wierd:
> >
> > my %h = ( a => 1, b => 2, c => 3 );
> > print join " ",%h,"\n";
> > { local $h{b} = "foo";
> > print join " ",%h,"\n";
> > }
> > print join " ",%h,"\n";
> >
> > prints
> >
> > a 1 b 2 c 3
> > a 1 b foo c 3
> > a 1 b 2 c 3
> >
> > Is that a temp thing? Is it as simple here as replacing local()
> > with temp? Or maybe let? (I still don't quite get let, either. :)
>
> Yep. s/local/temp/.
Sweet.
> C<let> is neat. The output from that if C<let> were involved would
> be:
>
> a 1 b 2 c 3
> a 1 b foo c 3
> a 1 b foo c 3
Ding! The little light goes on! lol!!!
Funny how sometimes a little example is all you need (even though
you've seen fifty already....)
> But the output from this:
>
> my %h = ( a => 1, b => 2, c => 3 );
> print join " ",%h,"\n";
> { let $h{b} = "foo";
> print join " ",%h,"\n";
> fail; # or die or (maybe) throw
> }
> print join " ",%h,"\n";
>
> would be:
>
> a 1 b 2 c 3
> a 1 b foo c 3
> a 1 b 2 c 3
>
> That is, C<let> makes its changes permanent only if its scope was
> exited successfully. It's implications are incredible when you
> consider exception safety (you get strong exception safety basically
> for free).
>
> Plus a bunch of other things we haven't thought of yet.
>
> Luke
*SWEET*!!
*Conditionally* temporal values!!!
I get it!