Michael Fowler wrote:
>
> > =head3 Merge C<TIESCALAR>, C<TIEHASH>, and C<TIEARRAY> into C<TIE>
>
> I'm not so sure about this.
I'm not either anymore. This will probably be removed from the next
version.
> > Instead, this RFC proposes that C<tie>'s operation become much more
> > fundamental, simply translating functions via the existing indirect
> > object syntax:
> >
> > tie Transaction %trans; # indirect object constructor
> > $trans{$var} = $value ; # $obj->STORE($var, $value);
> > lock $trans{$var}; # $obj->lock($var);
>
> Ignoring for a moment the ambiguities inherent in indirect object syntax
> (which we should all be aware of), what says $trans{$var} is not an object
> in itself, on which we want to call the lock method?
Well, currently indirect objects would not be called in the syntax
above. You would have to write:
lock {$trans{$var}};
Because an indirect object can only be a scalar, block, or bareword. So
I would say keeping a similar idea in place - if you want to use the
object method instead of the tied method, use braces - might be the best
way to disambiguate these. And remember you can also do this:
$trans{$var}->lock
If you want to make sure that the call is completely unambiguous.
However, one thing RFC 174 tries to accomplish is getting Perl to NOT
need the braces in these circumstances, which opens this whole can of
worms right back up. My current thinking is precedence rules:
1. tied object
2. indirect object
3. package function
4. CORE function
You could then use braces or -> if you wanted to force the indirect
object, as the above examples show (and how currently Perl 5 works).
I think this is actually the behavior you'd want. For example, imagine a
tied class whose purpose is to maintain filesystem objects. You'd want
the tied calls to take precedence, since you might have a special way of
sort'ing or push'ing your objects around. And force-disambiguating them
becomes pretty simple and consistent:
lock $trans{$var}; # use precedence rules
lock {$trans{$var}}; # indirect object (like Perl 5)
lock ($trans{$var}); # package or CORE function
This is actually pretty much how Perl 5 works already. The only thing
we've added is that the tied check is done in a slightly different way.
> > =head3 C<untie> should take all references out of scope
>
> I would argue that this should be handled with weak references, and not
> enforced by untie(). I don't necessarily want Perl deleting my object
> behind my back because I untied a variable.
Yeah, I agree with you, and I suspect that this problem will be
implicitly resolved by not having to mix object and tied calls. This'll
get the axe too.
-Nate
