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

=head1 TITLE

Objects: Autoaccessors for object data structures

=head1 VERSION

  Maintainer: Nathan Wiger <[EMAIL PROTECTED]>
  Date: 25 Aug 2000
  Last Modified: 15 Sep 2000
  Mailing List: [EMAIL PROTECTED]
  Number: 163
  Version: 2
  Status: Developing
  Original Author: James Mastros <[EMAIL PROTECTED]>

=head1 CHANGES

   1. Rewrote the RFC to use C<:laccess> and C<:raccess> attributes,
      instead of a single C<:accessible> tag.

   2. Added the ability for the attributes to take the name of the sub
      to create as an argument, allowing nested data structures.

   3. Extended the idea to encompass arrayrefs as well.

   4. Simplified the implementation.

=head1 ABSTRACT

This RFC proposes two attributes, C<:laccess> and C<:raccess>, which
when used on a blessed object variable, automatically construct either
an C<lvalue> or C<rvalue> autoaccessor respectively.

=head1 DESCRIPTION

=head2 Overview

Currently, to hide your data - even simply - you must create subs that
often look something like this:

   sub fullname {
       my $self = shift;
       @_ ? $self->{fullname} = $_[0]
          : $self->{fullname};
   }

This allows you to compartmentalize your data so that people can then
use it in their programs as:

   $r->fullname('Nathan Wiger');
   print $r->fullname;

For one or two data pieces, this is ok. But for lots of data, this chews
up a lot of time and code space unnecessarily.

This RFC proposes two simple attributes, C<:laccess> and C<:raccess>,
which would automate this process. The tags are kept intentionally
separate so that you can manually create an C<rvalue> sub, but use the
attribute to generate an C<lvalue> sub, or vice-versa.

=head2 The :raccess attribute

We'll start with the "easy one", which simply constructs an C<rvalue>
sub. Consider this code:

   package Bob;
   sub new {
       my $class = shift;
       my $self = {};
       $self->{name} :raccess = undef;
       $self->{age}  :raccess = undef;
       return bless $self, $class;
   }

Basically, two new C<rvalue> class methods would be created
automagically:

   sub name {
       my $self = shift;
       @_ ? $self->{name} = $_[0]
          : $self->{name};
   }

   sub age {     
       my $self = shift;
       @_ ? $self->{age} = $_[0]
          : $self->{age};
   }

These two subs could now be used in any C<rvalue> context by anyone who
used your class:

   my $jim = new Bob;
   $jim->name('Joe');
   $jim->age(42);
   print $jim->age;

The benefits are obvious: It's quick and easy, especially if you just
need a simple data wrapper.

=head2 The :laccess attribute

This tag works just like the above, only creating an C<lvalue> sub
instead. So this code:

   package JimmyHat;
   sub new {
       my $class = shift;
       my $self = {};
       $self->{size} :laccess = undef;
       return bless $self, $class;
   }

Would basically create the following C<lvalue> sub:

   sub size : lvalue {
       shift->{size};
   }   

Which could be used in any C<lvalue> context:

   my $raincoat = new JimmyHat;
   $raincoat->size = 42;
   $raincoat->size++;

Easy enough.

=head2 Specifying the name of the sub

The above cases are fine for simple situations, but often you will have
nested data structures. No fear, you can optionally specify the name of
the sub as an argument to the tag:

   package Johnson;
   sub new {
       my $class = shift;
       my $self = {};
       $self->{DATA}->{NUMERIC}->{S_size} :raccess('size') = undef;
       $self->{DATA}->{STRING}->{PL_name} :laccess('name') = undef;
       return bless $self, $class;
   }

This would basically have the effect of creating the following two subs:

   sub size {
       my $self = shift;
       @_ ? $self->{DATA}->{NUMERIC}->{S_size} = $_[0]
          : $self->{DATA}->{NUMERIC}->{S_size}
   }

   sub name : lvalue {
       shift->{DATA}->{STRING}->{PL_name};
   }

Which again, can be used in the appropriate contexts. Note this allows
you to maintain arrayref objects automatically as well:

   package Johnson;
   sub new {
       my $class = shift;
       my $self = [];
       $self->[0]->[2]->[3] :raccess('size') = undef;
       $self->[4]->[1] :laccess('name') = undef;
       return bless $self, $class;
   }

Although an arrayref is usually not the best data representation for
direct-access objects.

=head2 Combining attributes

You can, of course, combined the C<:laccess> and C<:raccess> attributes
on a given key to autogenerate accessors that work in both C<lvalue> and
C<rvalue> contexts, if you simply want to hide your data.

=head2 Mixing autoaccessors and real subs

The final case is where these become really powerful, but also makes the
implementation a little tricky. Here, we want to create an lvalue sub
that does something productive, but an rvalue autoaccessor:

   package 3rdLeg;
   sub new {
       my $class = shift;
       my $self = {};
       $self->{State}->{leg} :raccess = undef;
       return bless $self, $class;
   }

   sub leg : lvalue { 
       my $self = shift;
       # do a whole bunch of stuff ...
       $self->{State}->{leg};
   }

This would autogenerate an C<rvalue> autoaccessor for accessing C<leg>,
but would then use the sub that you had explicitly declared as the
C<lvalue> sub for C<leg>.

=head1 IMPLEMENTATION

In order for this to work, a couple things have to be true:

   1. Autoaccessor methods have to take precedence over declared
      methods in some way.

   2. A means for duplication of method namespace has to exist.

   3. The autoaccessor tags :laccess and :raccess must dictate
      that autoaccessors be declared for *only* that context;
      this is different from the meaning of lvalue subs which 
      can be used in either.

   4. There must be a way to set attributes on individual hash keys
      in Perl 6.

Note that throughout the RFC it has looked like this is a simple
sub-wrapper proposal, but it's not. As James Mastros (the original
author) said:

   The autoaccessor isn't a sub, it just behaves as if it were.
   This is the central point of autoaccessors.  The idea is that
   they should be faster then a method call, because you never
   change scope.  

Bingo. So, implementationally, it seems all of these could be satisfied
by having this:

   $r->method;

Do the following in order:

   1. Look for a declared autoaccessor for the given context.

   2. Look for a class method (same as currently).

A quick lookup in some type of centrally-maintained hash or something
should do the trick.

=head1 EXAMPLES

This example shows how much easier it would have been to write the
example on line 170 of perltoot.pod:

    package Person;
    use strict;
    
    ##################################################
    ## the object constructor (simplistic version)  ##
    ##################################################
    sub new {
        my $self  = {};
        $self->{name}  :laccess :raccess = undef;
        $self->{age}   :laccess :raccess = undef;
        $self->{peers} :laccess :raccess = [];
        return bless $self; 
    }

Note the lack of anything close to the next 15 lines of code; all of
that is taken care of with the simple attribute settings above.

=head1 MIGRATION

None. New functionality.

=head1 NOTES

I ripped the guts out of the original RFC in an attempt to simplify
things and get the concepts out there. However, a few things were lost
in the process:

   1. automatic dereferencing of return values
   2. readonly rvalue subs
   3. mutators

I suspect the first one should not be solved. The real idea behind
autoaccessors, as James pointed out, is speed and simplicity. As such,
requiring you to pass stuff around by reference:

   $r->autoaccessor = \@stuff;
   $r->autoaccessor(\@stuff);
   @stuff = @{$r->autoaccessor};

Is probably not such a bad idea, since references are faster anyways,
and this greatly simplifies what the autoaccessors have to do.

As for the second one, perhaps making the C<:raccess> tag a simple
accessor, unable to handle assignment (as noted below in the archives),
is really what should be done. This gives us back readonly C<rvalue>
subs, plus you can always use C<:laccess> to create an C<lvalue> sub for
assignment (which is probably cleaner anyways). I suspect this may be
the correct approach.

As for mutators, I suspect that most of the important functions should
be able to be handled by the separation and combination of the
C<:laccess> and C<:raccess> attributes, but feel free to point out if
this is completely wrong. :-)

=head1 REFERENCES

http://www.mail-archive.com/perl6-language-objects@perl.org/msg00098.html

http://www.mail-archive.com/perl6-language-objects@perl.org/msg00099.html

Reply via email to