Re: RFC 188 (v2) Objects : Private keys and methods
Damian Conway wrote: > > The problem with specifying them as attributes is that I do not believe > there is any way (or even any proposed way) of applying attributes to > a hash entrie or a hash slice, nor is there any way of *retrospectively* > applying an attribute to a hash that has already been declared elsewhere. You're correct. I personally think there should be. My examples have been based on the idea that this could be possible in Perl 6. I'm going to post a Nat-inspired 'IDEA' to perl6-language in a little bit (if my head doesn't explode first) and see how much it's shot at. -Nate
Re: RFC 188 (v2) Objects : Private keys and methods
The problem with specifying them as attributes is that I do not believe there is any way (or even any proposed way) of applying attributes to a hash entrie or a hash slice, nor is there any way of *retrospectively* applying an attribute to a hash that has already been declared elsewhere. Damian
Re: RFC 188 (v2) Objects : Private keys and methods
Jonathan Scott Duff wrote:
>
> With the exact same semantics? I.e.,
>
> my $hash{$key} : private = $val;
>
> makes %hash non-autovivifying, thus forcing the programmer to
> "declare" all of the hash keys he intends to use?
If you wanted to declare you lexical scope separate from your data
access properties, you could do so in this way:
my %hash;
{
$hash{$key} : private = $val;
$hash{$key} : public = $val2;
}
Here's my concern: Are "private" and "public" scopes? They don't appear
to be. They appear to be access modifiers, changing properties of the
variable they're attached to.
In this case, they're attributes, and belong after the variable, just
like ":64bit" or ":long". Regardless of their importance, if they're not
scope modifiers, it's inconsistent to put some before and some after
variables.
So,
my int $x :64bit = get_huge_value();
my string $self->{NAME} :private = shift;
See what I'm getting at? 'string' and 'int' are types. ':64bit' and
':private' are modifiers.
-Nate
Re: RFC 188 (v2) Objects : Private keys and methods
On Tue, Sep 19, 2000 at 12:35:31PM -0700, Nathan Wiger wrote:
> > This RFC proposes two new keywords -- C and C -- that limit
> > the accessibility of keys in a hash, and of methods.
>
> I still think these should be attributes across the board:
>
>my $hash{$key} : private = $val;
>my @hash{qw(_name _rank _snum)} : public;
>sub dostuff : private { }
>
> I'd be interested what others think.
With the exact same semantics? I.e.,
my $hash{$key} : private = $val;
makes %hash non-autovivifying, thus forcing the programmer to
"declare" all of the hash keys he intends to use? And how would the
programmer do this in your scheme?
my @hash{$key1,$key2,$key3} : private;
?
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Re: RFC 188 (v2) Objects : Private keys and methods
> This RFC proposes two new keywords -- C and C -- that limit
> the accessibility of keys in a hash, and of methods.
I still think these should be attributes across the board:
my $hash{$key} : private = $val;
my @hash{qw(_name _rank _snum)} : public;
sub dostuff : private { }
I'd be interested what others think.
-Nate
RFC 188 (v2) Objects : Private keys and methods
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 Sep 2000
Last Modified: 19 Sep 2000
Mailing List: [EMAIL PROTECTED]
Number: 188
Version: 2
Status: Developing
=head1 ABSTRACT
This RFC proposes two new keywords -- C and C -- that limit
the accessibility of keys in a hash, and of methods. Their primary use
would be to provide encapsulation of attributes and methods in
hash-based objects.
=head1 DESCRIPTION
=head2 Private hash entries
It is proposed that Perl 6 provide a unary function, C, that
restricts hash entries to the current package. The keyword could be applied to
a single hash entry:
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 => "demo", _rank => "private", _snum => 123 };
private bless { @attrs }, $class;
bless private { @attrs }, $class;
In all cases, a call to C would return its single argument.
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 or C -- see below)
=item 2.
mark the particular entry as being restricted to the package in which the
call to C occurs
=item 3.
mark any other existing entries of the hash as publicly accessible (see
L below).
=back
After a hash has been marked in this way, the specific key(s) would only be
directly accessible in the same package:
package MyClass;
sub new { bless private { secret => 'data' }, $_[0] }
package main;
my $obj = MyClass->new();
print $obj->{secret}; # dies, inaccessible entry
Attempts to autovivify keys of a C-ized hash would also be fatal:
package MyClass;
sub print_me { print $_[0]->{sekret} } # dies, no such entry
package main;
my $obj = MyClass->new();
print $obj->{public}; # dies, can't create entry
Once a hash has been C-ized, the only way to extend its set of
entries is via another call to C (or C -- see below):
sub new {
my ($class, %self) = @_;
bless private \%self, $class;
$self{seed} = rand; # dies, can't autovivify
private $self{seed} = rand; # okay
$self{seed} = rand; # now okay
}
Applying C to a hash slice would apply it individually to each
entry in the slice. Applying C to an entire hash (directly, or via
a reference) would apply it to every entry in the hash that is not already
private (or public -- see below).
=head3 C entries and inheritance
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 {
my ($class, @data) = @_;
bless private { data => [@data] }, $class;
}
package SortableBase;
use base 'Base';
sub sorted {
my ($self) = @_;
print sort @{ $self->{Base::data} };
}
Note, however, that it would still be a fatal error to attempt to access a
private entry outside its package's hierarchy, even with full qualification:
package main;
my $obj = Base->new(@data);
print $obj->{Base::data}; # dies, not in derived class
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:
package Base;
sub new {
my ($class, @data) = @_;
bless private { data => [@data] }, $class;
}
sub data { return $_[0]->{data} }; # Base::data
package Derived;
use base 'Base';
sub new {
my ($class, $derdatum, @basedata) = @_;
my $self = $class->SUPER::new(@basedata);
private $self->{data} = $derdatum;
return $self;
}
sub data { return $_[0]->{data} }; # Derived::data
Note that this solves the pernicious "data collision" problem in OO Perl.
=head3 Iteration of C-ized hashes
When a C-ized hash is iterated -- via C, C, or
C -- the only keys or values returned would be those that are
directly or indirectly accessible within the current package. Furthermore,
iterators that return keys would
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easyprogramming
On Tue, 19 Sep 2000, Adam Turoff wrote: > On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote: > > > I think I would be > > guardedly in favor of changing the default scope from global to local > > (although I have the feeling there is something I'm not considering). What > > does everyone else think? > > [the following is shown out of original order] > Really? You want a brand new $foo inside a while loop, distinct > from the one inside the surrounding sub? That is lost when the while > loop terminates? Urmm...I think maybe I just realized what it was that I wasn't considering. Never mind. Forget I said anything. *blush* Dave
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
On Tue, Sep 19, 2000 at 08:07:33AM -0700, Dave Storrs wrote: > On Tue, 19 Sep 2000, Nathan Wiger wrote: > > And then there's the lexical variable issue too: > > > >The default variable scope rules for Ruby (default: local) are > >much better suited for medium-to-large scale programming tasks; > >no "my, my, my" proliferation is needed for safe Ruby programming > > Actually, this is the bit that interests me. Most times, when you > create a variable, you *do* want local scope. Really? You want a brand new $foo inside a while loop, distinct from the one inside the surrounding sub? That is lost when the while loop terminates? > I think I would be > guardedly in favor of changing the default scope from global to local > (although I have the feeling there is something I'm not considering). What > does everyone else think? Sounds like a really bad idea. That's one of the reasons why people tend to hate tcl: everything is 'upvar' this and 'upvar' that to go up one level of scope. Z.
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easyprogramming
Dave Storrs wrote: > > >The default variable scope rules for Ruby (default: local) are > >much better suited for medium-to-large scale programming tasks; > >no "my, my, my" proliferation is needed for safe Ruby programming > > Actually, this is the bit that interests me. Most times, when you > create a variable, you *do* want local scope. I think I would be > guardedly in favor of changing the default scope from global to local > (although I have the feeling there is something I'm not considering). What > does everyone else think? There's been a big discussion on -strict on this. I invite you to join the list and check out RFC 106, which I feel is a pretty good proposal. But please, any further discussion on this needs to be on -strict, not here. Thanks. -Nate
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
[in Ruby documentation:]
> > The default variable scope rules for Ruby (default: local) are much
> > better suited for medium-to-large scale programming tasks; no "my,
> > my, my" proliferation is needed for safe Ruby programming
* Dave Storrs ([EMAIL PROTECTED]) [20 Sep 2000 02:08]:
> Actually, this is the bit that interests me. Most times, when you
> create a variable, you *do* want local scope.
[...]
Yes, but you'd need something that is a 'create variable' function.
Otherwise, if you typo you create a new locally scoped variable. That's
not what we want, surely?
The joy of 'my' (and the equivalent declarations in C/Pascal/etc.) is
that it traps such things.
cheers,
--
\def\Koschei{Iain Truskett}% http://eh.org/~koschei/
\def\WhoAmI#1#2#3#4#5#6{\tt#2#3\it#4#5\bf#6\sl!}\def\i{I}\def\f{i}\def\I
{\if\i\f\f\else\i\fi}\def\Am{am} \WhoAmI?\I\ \Am\ \Koschei\bye!
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
On Tue, 19 Sep 2000, Nathan Wiger wrote: > And then there's the lexical variable issue too: > >The default variable scope rules for Ruby (default: local) are >much better suited for medium-to-large scale programming tasks; >no "my, my, my" proliferation is needed for safe Ruby programming Actually, this is the bit that interests me. Most times, when you create a variable, you *do* want local scope. I think I would be guardedly in favor of changing the default scope from global to local (although I have the feeling there is something I'm not considering). What does everyone else think? Dave
Re: FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
> What sets Ruby apart is a clean and consistent > language design where everything is an object. I like this part. Assuming I ever finish my last RFC I'd like Perl to have embedded objects as well. The difference being Perl's wouldn't get in the way, unlike Python's. Of particular interest seems to be this link: http://www.ruby-lang.org/en/compar.html Which has a somewhat poignant analysis of Perl's OO: Ruby was a genuine easy-to-use object-oriented language from the beginning; whereas Perl's OOP features were added to non-OO Perl, so that these features are (unlike the rest of Perl) very clumsy and hard to use correctly and effectively. For many people and purposes, Ruby is a better OO Perl than Perl. And then there's the lexical variable issue too: The default variable scope rules for Ruby (default: local) are much better suited for medium-to-large scale programming tasks; no "my, my, my" proliferation is needed for safe Ruby programming Food for though at least. -Nate
Re: RFC 163 (v2) Objects: Autoaccessors for object data structures
On Mon, 18 Sep 2000, Glenn Linderman wrote: > This is an interesting comment to be made about an interesting side effect of > this proposal. [snip] > (1) array elements can be accessed by name > (2) member data can be looked up quicker (by array index, rather than by > hashed name) [snip] > new RFC: [snip] >my @foo; # empty array >$foo ['month'] = 10; # $#foo == 1, $foo[0] == 10 >$foo ['day'] = 20; # $#foo == 2, $foo [1] == 20 >$foo ['year'] = 30; # $#foo = 3, $foo [2] == 30 This is an interesting idea, certainly...my question is, if we go with this idea, what will hashes be used for? Or are they simply rendered obsolete? (I find that hard to believe, but I can't offhand think of a usage that this doesn't cover.) This will require every array to carry around an internal hash mapping its symbolic names to the index at which they point. Dave
Re: RFC 224 (v1) Objects : Rationalizing C, C, and C
On Mon, Sep 18, 2000 at 08:54:30AM -0600, Tom Christiansen wrote: > >This RFC proposes that rather than three separate mechanisms (in three > >separate namespaces) to determine object typing information, Perl 6 > >simply extend the C function to return all the necessary > >information in a list context. > > That sounds nice. It would also cure the funny business I tacitly > demonstrated in my last message in which ref defaults to $_ but > that reftype does not. It also reminds me of an RFC I did not submit, which was about reftype() and blessed() in the Scalar::Util package. Currently it is not very efficient to determine if a reference is blessed Graham.
FYI: Ruby 1.6.0 - An object-oriented language for quick and easy programming
I don't like OOP, you folks obviously do. Maybe docs/specs/... are interesting for you ... Have fun. From: [EMAIL PROTECTED] Newsgroups: fm.announce Subject: Ruby 1.6.0 - An object-oriented language for quick and easy programming Date: 19 Sep 2000 09:58:15 GMT application: Ruby 1.6.0 author: Yukihiro Matsumoto <[EMAIL PROTECTED]> license: GPL category: Development/Languages urgency: medium homepage: http://freshmeat.net/redir/homepage/915828413/ download: http://freshmeat.net/redir/download/915828413/ description: Ruby is a language for quick and easy programming. Similar in scope to Perl and Python, it has high-level data types, automatic memory management, dynamic typing, a module system, exceptions, and a rich standard library. What sets Ruby apart is a clean and consistent language design where everything is an object. Other distinguishing features are CLU-style iterators for loop abstraction, singleton classes/methods and lexical closures. Changes: A major release. Numerous bugfixes have been added. |> http://freshmeat.net/news/2000/09/19/969357725.html -- H.Merijn Brand Amsterdam Perl Mongers (http://www.amsterdam.pm.org/) using perl-5.005.03, 5.6.0, 5.7.1 & 516 on HP-UX 10.20 & 11.00, AIX 4.2 & 4.3, DEC OSF/1 4.0 and WinNT 4.0 SP-6a, often with Tk800.022 and/or DBD-Unify ftp://ftp.funet.fi/pub/languages/perl/CPAN/authors/id/H/HM/HMBRAND/
Re: RFC 218 (v1) C is just an assertion
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Sep 18, 2000 at 09:48:27AM +0100, Piers Cawley wrote:
> > Michael G Schwern <[EMAIL PROTECTED]> writes:
> > > Nope. fields::new() basically just does C > > [\%{"$class\::FIELDS"}], $class>, but the current pseudohash
> > > implementation doesn't care if something is an object or not. It just
> > > cares about either A) its type or B) what's in $ph->[0].
> >
> > Hmm... it still feels like undocumented behaviour. I'd definitely be
> > inclined to tighten up the base/fields behaviour. My feeling is that
> > the proposal makes them closer to the Right Thing.
>
> Its plenty documented. But if we simply put a bullet into
> pseudo-hashes, as per RFC 241, this all goes away.
Indeedly.
--
Piers
