> This is an interesting proposal, but it seems to be missing
> something, or maybe I am. It seems like once a single hash entry is
> marked private, that it is then impossible to mark future entries
> non-private...i.e. there is no corresponding unary "public"
> function.
That's r
Perl6 RFC Librarian wrote:
> The effects of applying C to a single hash entry would be to:
>
> =over 4
>
> =item 1.
>
> mark the entire hash as non-autovivifying (except via future calls to
> C -- see below)
This is an interesting proposal, but it seems to be missing something, or maybe I
am. I
> >In fact, I shall extend RFC 128 to allow subroutine parameter to specify
> >that they are non-autovivifying.
>
> I'm not sure why it matters to the subroutine. We've already got
> the hack so that
>
> fn( $a[$i] )
> or
> fn( $h{$k} )
>
> will onl
>I agree entirely.
>In fact, I shall extend RFC 128 to allow subroutine parameter to specify
>that they are non-autovivifying.
I'm not sure why it matters to the subroutine. We've already got the hack
so that
fn( $a[$i] )
or
fn( $h{$k} )
will only autoviv those puppies if you muddle
> >That seems reasonable--except that I don't believe exists() merits
> >any special treatment.
>
> More specifically, I think all non-lvalue context use of -> should be
> non-autoviv, whether exists or anything else.
I agree entirely.
In fact, I shall extend RFC 128 to allow
>That seems reasonable--except that I don't believe exists() merits
>any special treatment.
More specifically, I think all non-lvalue context use of -> should be
non-autoviv, whether exists or anything else.
--tom
>That's not required. All that is necessary is for C nodes
>in the op tree to propagate a special non-autovivifying context to
>subordinate nodes.
That seems reasonable--except that I don't believe exists() merits
any special treatment.
--tom
> Why can't we just apply the same warnings on hashes as we do on
> variables in Perl? Maybe a new lexical pragma:
>
> no autoviv; # any autovivification carps (not just
> # hashes)
>
> no autoviv 'HASH'; # no
> > print keys %hash, "\n";
> > exists $hash{key}{subkey};
> > print keys %hash, "\n";
>
> >Or did that get fixed when I wasn't looking?
>
> No, the -> operator has not been changed to do lazy evaluation.
That's not required. All that is necessary is for C nodes
in the o
On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>> exists (sometimes causes autovivification, which affects C)
>
>That's not technically accurate--exists never causes autovivification.
print exists $hash{foo}{bar}{baz};
use Data::Dumper;
print Dumper \
>On Tue, 05 Sep 2000 19:08:18 -0600, Tom Christiansen wrote:
>>> exists (sometimes causes autovivification, which affects C)
>>
>>That's not technically accurate--exists never causes autovivification.
> print exists $hash{foo}{bar}{baz};
> use Data::Dumper;
> print Dumpe
On Wed, Sep 06, 2000 at 12:05:21PM +1100, Damian Conway wrote:
>> 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).
>
> There are remarkably
> > > exists (sometimes causes autovivification, which affects C)
> >
> > That's not technically accurate--exists never causes autovivification.
> print keys %hash, "\n";
> exists $hash{key}{subkey};
> print keys %hash, "\n";
>Or did that get fixed when I wasn't looki
> > exists (sometimes causes autovivification, which affects C)
>
> That's not technically accurate--exists never causes autovivification.
print keys %hash, "\n";
exists $hash{key}{subkey};
print keys %hash, "\n";
Or did that get fixed when I wasn't looking
> exists (sometimes causes autovivification, which affects C)
That's not technically accurate--exists never causes autovivification.
--tom
> > mark the entire hash as non-autovivifying (except via future calls to
> > C -- 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
On Fri, Sep 01, 2000 at 08:59:10PM -, Perl6 RFC Librarian wrote:
> =head1 TITLE
>
> Objects : Private keys and methods
> =head1 ABSTRACT
>
> This RFC proposes a new keyword -- C -- that limits the
> accessibility of keys in a hash, and of methods. Its primary use would be to
> provide encap
On 1 Sep 2000, Perl6 RFC Librarian wrote:
> Private entries of hashes could be I accessed in packages
> that inherit from the entry's package, by qualifying (i.e. prefixing) the
> key with the entry's package name. For example:
>
> package Base;
>
> sub new {
>
> Will "private" be a true scoping keyword? Or under strict would you have
> to do this:
>
>private my %hash;
It's not a replacement for C, though C
*might* choose to overlook it. :-)
Damian
> private $hash{key};
> private $hash{$key};
> private $hashref->{key};
>
> or to a hash slice:
>
> private @hash{qw(_name _rank _snum)};
>
> or to a complete hash (either directly, or via a reference):
>
> private %hash;
> private { _name => "de
John Siracusa <[EMAIL PROTECTED]> writes:
> On 9/1/00 4:59 PM, Perl6 RFC Librarian wrote:
> > Once a hash has been C-ized, the only way to extend its set of
> > entries is via another call to C:
> >
> > sub new {
> > my ($class, %self) = @_;
> > bless private \%self, $class;
> >
"David E. Wheeler" <[EMAIL PROTECTED]> writes:
> On 1 Sep 2000, Perl6 RFC Librarian wrote:
>
> > This and other RFCs are available on the web at
> > http://dev.perl.org/rfc/
> >
> > =head1 TITLE
> >
> > Objects : Private keys and methods
>
> Here, here & amen, Damian! This one gets my insta
On 1 Sep 2000, Perl6 RFC Librarian wrote:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Private keys and methods
Here, here & amen, Damian! This one gets my instant vote!
David
> > private $self->{data} = $derdata;
>
> should be $derdatum here?
Yes. Thanks.
Damian
Kenneth Lee wrote:
>
> > Once a hash has been C-ized, the only way to extend its set of
> > entries is via another call to C:
> >
> > sub new {
> > my ($class, %self) = @_;
> > bless private \%self, $class;
> > private $self{seed} = rand;
> Once a hash has been C-ized, the only way to extend its set of
> entries is via another call to C:
>
> sub new {
> my ($class, %self) = @_;
> bless private \%self, $class;
> private $self{seed} = rand; # okay
> $self{se
> package Derived;
> use base 'Base';
>
> sub new {
> my ($class, $derdatum, @basedata) = @_;
> my $self = $class->SUPER::new(@basedata);
> private $self->{data} = $derdata;
On 9/1/00 4:59 PM, Perl6 RFC Librarian wrote:
> Once a hash has been C-ized, the only way to extend its set of
> entries is via another call to C:
>
> sub new {
> my ($class, %self) = @_;
> bless private \%self, $class;
> private $self{seed} = rand; # okay
> $s
00 21:15:31 +
> Received: (qmail 28917 invoked from network); Fri, 01 Sep 2000 21:15:30 +
> Date: Fri, 01 Sep 2000 15:15:26 -0600
> From: Tom Christiansen <[EMAIL PROTECTED]>
> Subject: Re: RFC 188 (v1) Objects : Private keys and methods
> In-reply-to: Messa
>=head1 REFERENCES
>Christiansen & Torkington, I, pp. 470-472.
>Conway, I, pp. 309-326.
One might add refs to Camel-3's new OO chapter on privacy approaches.
--tom
>=head2 Private methods
>The C 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:
>package Base;
>
>sub new { ... }
>
>private sub check { ... }
>
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Private keys and methods
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 1 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 188
Status: Developing
32 matches
Mail list logo
