RFC 319 (v1) Transparently integrate C<tie>

This and other RFCs are available on the web at
  http://dev.perl.org/rfc/

=head1 TITLE

Transparently integrate C<tie>

=head1 VERSION

  Maintainer: Nathan Wiger <[email protected]>
  Date: 25 Sep 2000
  Mailing List: [email protected]
  Number: 319
  Version: 1
  Status: Developing

=head1 ABSTRACT

B<RFC 200> proposes many enhancements to C<tie> to make it more
versatile and multipurpose. However, it still relies on using the C<tie>
keyword to create a C<tie>d variable, keeping C<tie> separate.

Python and lots of other languages have figured out how to implement
fully-integrated data, operator, and method overloading. Perl should
too, without looking horrendously OO-ish like Python.

=head1 DESCRIPTION

=head2 Implicit C<tie>

This RFC proposes that C<tie> be integrated with Perl from the ground
up, and not remain as a separate concept. Instead, classes that provide
C<TIE*> methods will have them automatically invoked on assignment. For
example:

   my bigint $x = 5;   # bigint->TIESCALAR($x); $x->STORE(5);

The C<TIE*> methods are called implicitly on I<first data store>. So:

   my packed $a;       # just an assertion, RFC 218
   $a = get_binary;    # packed->TIESCALAR($a); $a->STORE(..);
   $a = more_data;     # $a->STORE(...);
   $a++;               # $a->STORE($a->PLUS(1));
   undef $a;           # $a->DESTROY;

   my int @b :64bit;   # again, just an assertion
   @c = @b;            # empty list passed still
   @b = (1,2);         # int->TIEARRAY(@a, '64bit'); @b->CLEAR(...); ...

Note that the C<TIE*> methods will only be called if they exist, just
like currently. If a given C<TIE*> method does not exist, then the
appropriate error should be spit out:

   my Pet @spot = ("fluffy");
   Can't locate method "TIEARRAY" via package "Pet"

In this case, the package C<Pet> has declared that it can't handle
arrays, which is just fine.

=head2 Optimization and Inheritance

One of the main goals behind doing something like this is being able to
create custom variable types that can take advantage of optimizations,
and having these variables walk and talk like builtins.

For this reason, it is further proposed that all variable types be
handled through basic method inheritance in Perl 6. Essentially,
everything becomes an object and is fully overrideable and redefineable.
So, for example:

   package var;         # main variable class

   # all the main Perl internal methods are defined, such
   # as TIESCALAR, TIEARRAY, STORE, FETCH, etc

   package int;
   use base 'var';

   # ideas for RFC 303
   use optimize storage => 16,   # how much space
                growable => 1,   # can we grow?
                growsize => 8,   # how much to grow by
                integer => 1,    # support ints
                string => undef, # but not strings
                float => undef,  # or floats
                promote => 'bigint';  # promote to class
                                      # when outgrow

   # TIESCALAR, STORE, etc need not be redefined, since
   # they could simply inherit from var's, but perhaps
   # we could define special math ops per RFC 159.

In this example, we've used the C<int> class to define several key
optimizations for Perl to use. Since C<var> is the grandfather class of
all variables, its C<STORE> and C<FETCH> methods can be used, which
actually do the internals of storing values and using the hints set by
the C<use optimize> pragma.

In reality, builtin types will be implemented in C and not Perl.
However, that doesn't mean that other custom classes couldn't still
inherit from these types as well. For example:

   package CoolInt;      # my own, real cool int
   use base 'int';
   # setup all my methods and optimizations

So, dispatch for builtin types could be very fast - the correct C<STORE>
et al methods (written in C) are simply called. Then, user-defined types
would be derivable from builtin types with some slowdown, but nowhere
near as bad as C<tie>. Code could simply look like this:

   use CoolInt;
   my CoolInt $x = 42;   # CoolInt->TIESCALAR($x); $x->STORE(42);

Thus making it transparent to the user, and not requiring either of
these:

   # Use our constructor
   my $x = CoolInt->new(42);

   # Use a tie interface
   tie CoolInt $x;
   $x = 42;

=head2 Type checking

Nat's upcoming RFC on type checking will propose a C<use strict 'types'>
pragma. Type checking would be trivial to implement by combining aspects
of this RFC with the C<use optimize> concept:

   package Pet : interface;   # RFC 265
   use optimize types => ['Dog', 'Cat'];

With this declaration, Perl is now told that anything of type C<Pet> can
be either a C<Dog> or a C<Cat>. This means that in your main code:

   use strict 'types';
   my Pet $spot = new Camel;   # oops!

The second line would raise a syntax error.

=head2 The C<:tie> attribute

Making C<tie> this seamless may scare some people. In this case, we may
wish to add an C<:tie> attribute that can be specified on the
C<package>:

   package Pet : tie;     # will be auto-tied

Placing this on the package, and not individual subs, makes more sense
because it dictates how all the package's methods interact.

The idea here is that by fully integrating these concepts, a separate
C<tie> function will no longer be necessary and will instead be replaced
by a simple C<:tie> package attribute (or no attribute at all).

=head1 IMPLEMENTATION

This would only work if the proposed embedded C<tie> in Perl 6 was not
dog slow. In fact, it would only work if the dispatch mechanism for this
type of thing becomes really fast. If vtable stuff is embedded from the
ground up, and all data stuff is implemented this way, it might be
possible.

The basic idea is that the name of the method used to store data B<is>
C<STORE>, even internally. Instead of C<mg.c> having to call special
functions and make special checks, C<STORE> is called, whatever that
C<STORE> may be. Thus OO inheritance is embedded and fast.

=head1 MIGRATION

This should be transparent if implemented correctly, and should not
require migration.

=head1 REFERENCES

RFC 200: Objects: Revamp tie to support extensibility (Massive
         tie changes)

RFC 303: Keep C<use less>, but make it work.

RFC 73:  All Perl core functions should return objects

RFC 265: Interface polymorphism considered lovely

RFC 218: C<my Dog $spot> is just an assertion

RFC 171: my Dog $spot should call a constructor implicitly

RFC 161: Everything in Perl becomes an object. 

RFC 137: Overview: Perl OO should I<not> be fundamentally changed

RFC 270: Replace XS with the C<Inline> module as the standard way
         to extend Perl.