On Fri, Sep 08, 2000 at 04:57:46AM -0000, Perl6 RFC Librarian wrote:
> =head3 Merge C<TIESCALAR>, C<TIEHASH>, and C<TIEARRAY> into C<TIE>
> 
> In practice, people rarely make a class that C<tie>s multiple data types
> through the same interface. The reason is that C<STORE>, C<FETCH>,
> C<DESTROY>, and other methods overlap. As such, it is more feasible to
> create several different modules; witness C<Tie::Array>, C<Tie::Scalar>,
> C<Apache::Session>, and other modules.

I'm not so sure about this.  As Schwern mentioned, it'd be nice to know what
exactly is being tied, and he suggested a first argument of the type.  But
isn't this just moving the information from the subroutine name into @_? 
I'd much rather Perl say "oh, you can't tie a hash, there's no TIEHASH"
than be forced to switch on the first argument and raise a fatal exception
if I can't support what's being tied.

 
> 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?


> =head3 C<untie> should take all references out of scope
> 
> When called, C<untie> currently suffers the somewhat nasty problem of
> not being able to automatically destroy inner references. This means if
> you've mixed OO and C<tie>d calls, you may not be able to destroy your
> tied object as easily as you like. C<untie> should forceably destroy
> hanging references. [2]

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.


Michael
--
Administrator                      www.shoebox.net
Programmer, System Administrator   www.gallanttech.com
--

Reply via email to