On Fri, Sep 01, 2000 at 08:59:10PM -0000, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Objects : Private keys and methods
> =head1 ABSTRACT
>
> This RFC proposes a new keyword -- C<private> -- that limits the
> accessibility of keys in a hash, and of methods. Its primary use would be to
> provide encapsulation of attributes and methods in hash-based objects.
Interesting.
> mark the entire hash as non-autovivifying (except via future calls to
> C<private> -- see below)
This bothers me. Name an operation in perl that, when applied to a single
element of an aggregate, affects all other elements of the aggregate
(especially future, as-yet-unborn elements).
Random idea: Only apply C<private> to hashes, not elements. This causes
the package name to automatically be added to the keys in the hash and
only allows access to the hash in the current package. You can still
autovivify elements in the hash, but they're autovivifically private.
(Yes, I realize that you then would want a way to make some of them
public, but I think with an extra indirection and delegation that
could be made quite simple (but I could be wrong) Something like
this maybe (sans delegation)? :
my %hash = (
'private' => private { ... },
'public' => { ... }
);
)
> Because private entries are only directly acccessible within their own
> package, a hash could be given two private entries with the same key,
> but associated with different packages. For example:
Ohh, neat.
> =head2 Private methods
>
> The C<private> keyword could also be applied to subroutines, to restrict
> where they may be called. Access rules similar to those for private hash
> entries would apply:
I'd think this too would fall out of delegation. To quote your RFC 193:
> That is, calls like:
>
> $obj->method3(@args);
> $obj->method5(@other_args);
>
> would act as if they were:
>
> $obj->{attr1}->method3(@args);
> $obj->{attr2}->method5(@other_args);
That could easily carp if the attributes are private.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
