This and other RFCs are available on the web at http://dev.perl.org/rfc/ =head1 TITLE Objects: Revamp tie to support extensibility (Massive tie changes) =head1 VERSION Maintainer: Nathan Wiger <[EMAIL PROTECTED]> Date: 07 Sep 2000 Mailing List: [EMAIL PROTECTED] Version: 1 Number: 200 Status: Developing Requires: RFC 159, RFC 174 =head1 ABSTRACT C<tie> is really cool. Mostly. It has an amazing amount of power in concept, but suffers from several limitations which this RFC attempts to address. =head1 DESCRIPTION =head2 Overview Many people have expressed problems with tie, including Larry [1]. C<tie> suffers from several limitations: 1. It is non-extensible; you are limited to using functions that have been implemented with tie hooks in them already. 2. Any additional functions require mixed calls to tied and OO interfaces, defeating a chief goal: transparency. 3. It is slow (at least slower than other objects) 4. You can't easily integrate tie and operator overloading. 5. If defining tied and OO interfaces, you must define duplicate functions or use typeglobs. 6. Some parts of the syntax are, well, kludgey This RFC attempts to address all of these points with some changes to syntax and implementation concepts. It interacts with the concept of B<polymorphic objects>, described in L<RFC 159>, to provide a simple and extensible framework. =head2 New Concepts This RFC proposes two key principles that will provide a more general-purpose C<tie> framework: 1. Operator, data, and syntax overloading will be done via the ALLCAPS methods described in RFC 159. 2. All other functions are directly translated via the indirect object syntax. In addition, the declaration of a tie statement is suggested to be changed into a standard indirect object function: $object = tie Tie::Class @array_to_tie; The default C<tie>ing would be performed by C<UNIVERSAL::tie>, which would be a new method that properly "blessed" the tied variable and then simply turned around and called the class's C<TIE> method, similar to how the builtin C<tie> works currently. There are many changes, so let's go through them one at a time and then revisit how they will all tie (ha-ha) together at the end. =head2 Syntax Changes =head3 Drop C<tie> builtin and replace with C<UNIVERSAL::tie> As mentioned above, this allows us to call C<tie> in a simple indirect object form. This eliminates one more special-case function which currently requires that quotes be placed around the class name. This syntax should simply be modified to be called on the object it will be tied to, since C<tie> is after all an object constructor. =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. =head3 Drop C<TIEHANDLE> Thanks to the below syntax, differentiating between filehandles and other scalars is no longer important. It would also be very difficult to make this distinction, since in Perl 6 filehandles are intended to be C<$scalars>. =head3 Continue to do data handling through ALLCAPS methods This will not change. C<STORE> and C<FETCH>, along with other functions described in RFC 159 and below, will continue to do data handling. In addition, these methods will be used for operator overloading as well. =head3 Perform functions through the indirect object syntax Currently, C<tie> incurs a fairly substantial overhead (depending on your application) because function calls such as this: push @tied_array, $value; Must be internally transformed into this: $self->PUSH($value); In addition, you are bound by the methods that the designers have implemented. While Perl 5.6 finally has a fairly substantial collection, nonetheless it is easy to imagine that future functions will arise which you want to C<tie>, but which support has not been added for yet. Plus, if you want to support extra methods of your own, you must mix object and tied calls: $obj = tie %trans, 'Transaction'; $trans{$var} = $value; $obj->lock($var); Unfortunately, this defeats one of the key purposes of tie, which is OO transparency. And, creating a class that supports both OO and tied interfaces is difficult, requiring typeglobs or duplicate handler functions. 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); delete $trans{$var}; # $obj->delete($stuff); foo %trans; # $obj->foo; %trans = (); # $obj->CLEAR; Note that operator and data access is still done by ALLCAPS methods, in fact the same ones described in L<RFC 159>. The reason for this is symmetry: Like polymorphic objects, we can now warp our C<tie>d classes in whatever way we desire. In fact, one could imagine a simple matrix math class: tie My::Matrix @a; @a + @b; # $obj->ADD(@b); $a[0] = 4; # $obj->STORE(0, 4); @a * @b; # $obj->MUL(@b); special_stuff @a; # $obj->special_stuff; We also no longer have to care about the differences between filehandles and other scalars: tie My::Handle $FILE; print $FILE @stuff; # $obj->print(@stuff); flush $FILE; # $obj->flush; close $FILE; # $obj->close In each of these examples, the variable that is being C<tie>d acts like little more than a syntactic mask over an object. Translation is potentially much faster because the indirect object syntax is used. Note that this can even be accomplished for functions such as push (where a comma follows the object) if L<RFC 174>, which addresses changes to indirect object parsing, is adopted. =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] =head2 Function Summary This is a summary of all the functions that should be implemented in C<tie> in Perl 6. Any functions not mentioned here should be dropped from the C<tie> interface in Perl 6, instead replaced with the automatic indirect object calling form: General Methods ----------------------------------------------------- TIE Constructor DESTROY Destructor STORE Data storage FETCH Data retrieval Hash-Specific Methods ----------------------------------------------------- FIRSTKEY Get first key during keys/values/each NEXTKEY Iterate through keys/values/each CLEAR Clearing or resetting of hash Array-Specific Methods ----------------------------------------------------- FETCHSIZE scalar @array (basically) STORESIZE Set $#array EXTEND Pre-extend array size CLEAR Clearing or resetting of array Other Methods ----------------------------------------------------- Include all other methods described in RFC 159 That's it. Everything else can be automatically invoked through a slightly-modified indirect object syntax (including C<exists>, C<delete>, and so forth). =head2 Example: Transaction Here is an example of how a tied class may be implemented under this RFC: # A class to do some simple transactional locking # A much more robust version could implement RFC 130 package Transaction; use Carp; use strict; # Include tied interface sub TIE { my $self = self; # RFC 152 :-) bless {@_}, $self; } # And also include OO interface per RFC 189 # Note: For both of these, simply allow UNIVERSAL::new and # UNIVERSAL::tie to take care of the actual calls. sub NEW { my $self = self; bless {@_}, $self; } sub RENEW { croak "Fatal: Reblessing transactional hashes not allowed!"; } # Include those functions we want to override # Our internal data functions are in ALLCAPS and most come # from RFC 159 (as well as previous tie implementations) sub STORE { my $self = self; if ($self->{LOCKED}->{$_[0]}) { croak "Fatal: Attempt to modify locked key $_[0]!"; } $self->{DATA}->{$_[0]} = $_[1]; } sub FETCH { my $self = self; return $self->{DATA}->{$_[0]}; } # Hash-specific method sub CLEAR { my $self = self; # Check for any locked values still remaining if (keys %{$self->{LOCKED}}) { croak "Fatal: Attempt to clear hash with locked keys!"; } undef $self->{DATA}; } # Want to override what each() and keys() do # Mostly stolen from Camel-3 p. 383 sub FIRSTKEY { my $self = self; my $temp = keys %{$self->{DATA}}; return scalar each %{$self->{DATA}}; } sub NEXTKEY { my $self = self; return scalar each %{$self->{DATA}}; } # Override addition just for demonstration purposes sub ADD { my $self = self; $self->{DATA}->{$_[0]} += (rand * $_[1]); } # Now add any Perl or custom functions that we want these # objects to be able to handle sub lock { my $self = self; $self->{LOCKED}->{$_[0]} = 1; } sub unlock { my $self = self; carp "Warning: Key $_[0] already unlocked" unless $self->{LOCKED}->{$_[0]}; delete $self->{LOCKED}->{$_[0]}; } sub unlock_all { my $self = self; carp "Notice: All values already unlocked" unless $self->{LOCKED}; undef $self->{LOCKED}; } # Warn if we have locked values still sub DESTROY { my $self = self; if (keys %{$self->{LOCKED}}) { carp "Warning: Destroying transaction with locked keys!"; } undef $self->{LOCKED}; undef $self->{DATA}; } # Use our Transaction class package main; use CGI; my $cgi = new CGI; tie Transaction %trans; # Transaction->TIE (thru UNIVERSAL::tie) # Generate our session id # Yes I know this is massively insecure ;-) srand; $trans{session} = rand; # All of these call $obj->STORE($var) $trans{name} = $cgi->param('name'); $trans{email} = $cgi->param('email'); $trans{cc} = $cgi->param('cc'); $trans{amount}= $cgi->param('amount'); # Lock our amount while we're charging the card... lock $trans{cc}; # $obj->lock('cc'); lock $trans{amount}; # $obj->lock('amount'); for ($try = 0; $try < 3; $try++) { # Attempt to charge them next unless &charge_card($trans{cc}, $trans{amount}); $trans{chargedate} = localtime; } unlock $trans{cc}; # $obj->unlock('cc'); # Check if we were successful die "Could no charge card $trans{cc}" unless $trans{chargedate} # Increment our session id # ++$trans{session} calls $obj->STORE($obj->ADD('session', 1)) $cgi->param('session') = ++$trans{session}; # Kill our transaction unlock_all %trans; # $obj->unlock_all; Note how we are easily able to add three new methods, C<lock>, C<unlock>, and C<unlock_all>, which are directly translated for us, meaning we don't have to mix OO and tied variable calls. This provides true object transparence. Note also how our overloaded C<ADD> operator is used to increment our session number as well, all transparently to the user. =head1 IMPLEMENTATION Conceptually, implementation is straightforward, but quite different from tie's current form: 1. Drop C<tie> builtin and replace with C<UNIVERSAL::tie> 2. Merge all constructors into single C<TIE> function 3. Drop internal function translation and instead translate based on modified indirect object syntax 4. Modify C<untie> to forceably destroy all references Actually, C<tie> might be able to be handled completely by a preprocessor of sorts. Consider this code: tie My::Matrix @a, [ 1, 2, 3 ]; @a = @a + @b; # $obj->CLEAR; $obj->STORE($obj->ADD(@b)); @a = @a * @b; # $obj->CLEAR; $obj->STORE($obj->MUL(@b)); push @a, $value; # $obj->push($value); If Perl simply ran something like a C<s/\@a\b\s*,?/\$obj/g> over the code internally, then all of this would become: $obj = My::Matrix->tie([1, 2, 3]); $obj = $obj + @b; # $obj->CLEAR; $obj->STORE($obj->ADD(@b)); $obj = $obj * @b; # $obj->CLEAR; $obj->STORE($obj->MUL(@b)); push $obj $value; # $obj->push($value); And now it is easy to reparse and call functions/operators correctly simply based on the indirect object syntax and concept of polymorphic objects. In any event, this is a massive oversimplification, but at the very least it sheds some additional light on the concept. C<tie> is used to hide polymorphic objects, but the actual operator and data overloading methods are simply member functions of these objects, similar to currently. The hooks C<tie> currently relies on for functions are no longer necessary and instead replaced with low-level hooks for polymorphic objects. =head1 MIGRATION Syntactically, many users will only see that some functions have changed case or otherwise been altered slightly. As such, the p52p6 translator should be able to change this relatively easily. Many of the changes in this RFC build on and add power to C<tie>, so do not require translation because they are new. =head1 NOTES [1] http://www.mail-archive.com/[email protected]/msg02087.html [2] Camel-3 p. 395 has an excellent description of this problem. =head1 REFERENCES RFC 159: True Polymorphic Objects RFC 174: Parse C<func($obj, @args)> as C<func $obj (@args)> RFC 189: Objects : Hierarchical calls to initializers and destructors RFC 152: Replace $self in @_ with self() builtin (not $ME) RFC 130: Transaction-enabled variables for Perl6 Camel-3 Chapter on C<tie>, p363-398 Thanks to Nathan Torkington for his input and support
