Re: RFC 218 (v1) Cmy Dog $spot 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 Cbless
[\%{"$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
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 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: 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: 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
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: RFC 188 (v2) Objects : Private keys and methods
This RFC proposes two new keywords -- Cprivate and Cpublic -- 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
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
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
