> How about also just ":access" to do both? It would seem to be the
> most common case.
I was trying to conserve keywords, but I'm not opposed to this.
> > =head2 Mixing autoaccessors and real subs
> >
> 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.
> I also don't see that the optimization of one half of the accessor vs
> the other is worth the trouble.
Well, it depends on how much faster the autoaccessor is. If it is much
faster, and you need to access a whole bunch of data repeatedly, then
this makes sense. But if the autoaccessor is about the same as a sub
speed-wise, then screw it, I agree.
> 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);
I think attributes are a nicer way of handling stuff attached to data,
because it's right there by the data looking at you. But this:
> This also means accessors are defined on a per class basis rather than
> per object (which is potentially extremely confusing and difficult to
> implement).
Is a good point. I could see something like:
use accessor (name => '$SELF->{DATA}->{C_name}', 'lvalue');
But I'll have to think about this a little more.
> > $r->method;
> > 1. Look for a declared autoaccessor for the given context.
>
> Context. I hope this means context of the object $r?
Yep. Will clarify.
> > 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.
Yeah, check out this email:
http://www.mail-archive.com/perl6-language-objects@perl.org/msg00099.html
The idea I originally had was that :raccess would specify something was
an rvalue accessor which only returned a value, and couldn't take
arguments. I think this is probably the way to go, otherwise we have to
start adding other keywords, properties, etc, which really complicate
things too much.
> 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.
Couldn't quite see what you were getting at here - maybe a little
clarification. I'm pretty sure I understand ("autoderef bad, but forced
copy bad too") but want to make 100% sure.
-Nate
