On Mon, Sep 18, 2000 at 04:58:45AM -0000, Perl6 RFC Librarian wrote:
> =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.
How about also just ":access" to do both? It would seem to be the
most common case.
> =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:
I really don't see how this is necessary. If you have to write a
custom accessor, you might as well write the whole thing. Doesn't
save much programming effort to be able to still use the default for
one context and custom for other, and it would greatly simplify the
implementation without it.
I also don't see that the optimization of one half of the accessor vs
the other is worth the trouble.
> =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.
If we eliminate the thing about mixing, this goes away.
> 4. There must be a way to set attributes on individual hash keys
> in Perl 6.
While in general this might be a good idea, is it really necessary for
this proposal? How about this:
package Foo;
use laccess qw(this);
use raccess qw(foo);
use access qw(up);
sub new { bless {} }
my $foo = Foo->new;
$foo->this = 'that';
$foo->foo('bar');
$foo->up = 'down';
$foo->up('sideways');
This also means accessors are defined on a per class basis rather than
per object (which is potentially extremely confusing and difficult to
implement).
Although this makes your C<$self->{DATA}->{NUMERIC}->{S_size} :raccess('size') =
undef;> case tricky to emulate. It also makes
combining attributes difficult. Will ponder.
> 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. I hope this means context of the object $r?
> 2. readonly rvalue subs
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00096.html
implies that this isn't needed because of the proposed :constant hash
attribute. This isn't enough. There is a distince difference between
an attribute that is constant, and one which is read-only. That
difference being that a read-only value should be able to be written to
*privately*.
Consider the case of an accessor which returns a list of object fields
which have changed since the last time the object was changed
(Class::DBI does this). The list of obviously not constant, yet the
accessor should be read-only.
> 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};
I was about to say that :deref wouldn't be a bad idea, but that would
just be shifting the problem from pass-by-reference to pass-by-value.
$r->autoaccessor = @stuff;
@stuff = $r->autoaccessor;
If this is made equivalent to your code above, it makes pass-by-value
icky.
$r->autoaccessor = @{[@stuff]};
If we make it copy the value of @stuff first (like $r->autoaccessor =
[@stuff] currently does) then this all encourages inefficiencies.
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
<GuRuThuG> make a channel called Perl, and infest it with joking and
fun....it doesnt make alot of sense.
