| Note: these documents may be out of date. Do not use as reference! |
To see what is currently happening visit http://www.perl6.org/
Objects: Autoaccessors for object data structures
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
None. New functionality.
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. :-)
RFC 279: my() syntax extensions and attribute declarations
RFC 337: Common attribute system to allow user-defined, extensible attributes