[% setvar title Objects: Autoaccessors for object data structures %]

This file is part of the Perl 6 Archive

Note: these documents may be out of date. Do not use as reference!

To see what is currently happening visit http://www.perl6.org/

TITLE

Objects: Autoaccessors for object data structures

VERSION

  Maintainer: Nathan Wiger <nate@wiger.org>
  Date: 25 Aug 2000
  Last Modified: 29 Sep 2000
  Mailing List: perl6-language-objects@perl.org
  Number: 163
  Version: 3
  Status: Frozen
  Original Author: James Mastros <james@rtweb.net>
  Requires: RFC 279, RFC 337

ABSTRACT

This RFC proposes three attributes, :laccess, :raccess, and :roacess, which when used on a blessed object variable, automatically construct an lvalue, rvalue, or readonly rvalue autoaccessor, respectively.

NOTES ON FREEZE

Pretty much everyone liked the basic idea, but the implementation needs some work. In particular, Michael Schwern pointed out that using attributes to declare these may not be the best method. RFC 337 proposes a use of attributes that would allow them to basically act as specialized subs, so this concern may be solved. Regardless, it is an issue that needs revisiting; a package-wide pragma may be the best solution.

DESCRIPTION

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 the attributes :laccess, :raccess, and $:roaccess which would automate this process. The tags are kept intentionally separate so that you can manually create an rvalue sub, but use the attribute to generate an lvalue sub, or vice-versa.

The :raccess attribute

We'll start with the "easy one", which simply constructs an 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 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 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.

The :roaccess attribute

This works identically to the above sub, with the difference that modification of its value is not allowed; it is readonly. As such, the following:

   $self->{name} :roaccess = "Nate";

Would create the equivalent of the following sub:

   sub name {
       my $self = shift;
       croak "Attempt to assign to readonly rvalue autoaccessor" if @_;
       return $self->{name};
   }

As such, you could fetch values but not set them:

   print $r->name;     # "Nate";
   $r->name('Jim');    # oops!

The second one should result in an exception being thrown.

The :laccess attribute

This tag works just like the above, only creating an 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 lvalue sub:

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

Which could be used in any lvalue context:

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

Easy enough.

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.

Combining attributes

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

The :roaccess can only be combined with the :laccess tag. In fact, the :roaccess should probably not be combinable with any other tag, but this RFC does not require this.

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 rvalue autoaccessor for accessing leg, but would then use the sub that you had explicitly declared as the lvalue sub for leg.

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. See RFC 279 and RFC 337.

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,
      context of course being where $r is.

   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.

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.

MIGRATION

None. New functionality.

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 :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 rvalue subs, plus you can always use :laccess to create an 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 :laccess and :raccess attributes, but feel free to point out if this is completely wrong. :-)

REFERENCES

RFC 279: my() syntax extensions and attribute declarations

RFC 337: Common attribute system to allow user-defined, extensible attributes

www.mail-archive.com

www.mail-archive.com

www.mail-archive.com

www.mail-archive.com