Hello all,
This is a summary for last week on the ruby-dev mailing list.
[ruby-dev:20127] protected_instance_methods(true)
Hara suggested that klass::protected_instance_methods(true)
return an array of protected methods which are usable in
klass, not defined in klass. Matz replied he thought it’s
a good behavior but difficult to implement.
[ruby-dev:20129] Re: Array#map
Matz posted the reasons why the development of rite
is slow:
- it’s hard to maintain 1.6.
- specification of 1.8 is not freezed.
- it’s easy to change 1.8.
- there’s concern about 1.9
And there are still some problems of 1.8:
- Proc#yield (Proc vs Block)
- assinment to $stdin/$stdout/$stderr
Regards,
TAKAHASHI ‘Maki’ Masayoshi E-mail: maki@rubycolor.org
In article 20030508011603F.maki@rubycolor.org,
Hello all,
This is a summary for last week on the ruby-dev mailing list.
Matz posted the reasons why the development of rite
is slow:
- it’s hard to maintain 1.6.
Wouldn’t it be best if someone else (or multiple someone elses) took over
maintenance of the stable releases, thus freeing matz to work on rite? I
think this is what they do in the Perl world; Larry doesn’t have to worry
about maintaining Perl 5 stuff, others do that while Larry is working on
Perl 6.
- specification of 1.8 is not freezed.
Is this related to the 'there are still some problems of 1.8:" section
below?
What does this mean?
- there’s concern about 1.9
What is the concern?
And there are still some problems of 1.8:
- Proc#yield (Proc vs Block)
- assinment to $stdin/$stdout/$stderr
Phil
···
TAKAHASHI Masayoshi maki@rubycolor.org wrote:
There is such an abundance of /.*methods/ methods that I make the
following wistful suggestion.
How about a single method “methods” that takes arguments:
methods(:instance)
methods(:private, :instance)
methods(:public, :class)
methods(:singleton)
etc.
I can’t see it being done - too disruptive - but an interesting thing
to think/talk about, anyway.
Cheers,
Gavin
···
On Thursday, May 8, 2003, 2:35:14 AM, TAKAHASHI wrote:
[ruby-dev:20127] protected_instance_methods(true)
Hara suggested that klass::protected_instance_methods(true)
return an array of protected methods which are usable in
klass, not defined in klass. Matz replied he thought it’s
a good behavior but difficult to implement.
ptkwt@shell1.aracnet.com (Phil Tomson) wrote:
Matz posted the reasons why the development of rite
is slow:
- it’s hard to maintain 1.6.
Wouldn’t it be best if someone else (or multiple someone elses) took over
maintenance of the stable releases, thus freeing matz to work on rite? I
think this is what they do in the Perl world; Larry doesn’t have to worry
about maintaining Perl 5 stuff, others do that while Larry is working on
Perl 6.
- specification of 1.8 is not freezed.
Is this related to the 'there are still some problems of 1.8:" section
below?
Yes.
What does this mean?
Sorry, I mean that it’s easier for Matz to maintain 1.8
than to tackle Rite.
- there’s concern about 1.9
What is the concern?
New features of 1.9, ex. M17N, new regex engine, generational
GC, new (original) stdio, and so on.
see: [ruby-talk:35416] [ruby-talk:36757] [ruby-core:937]
[ruby-core:939]
Regards,
TAKAHASHI ‘Maki’ Masayoshi E-mail: maki@rubycolor.org
I’m not sure that this is “dispatching features” so much as
“filtering”. I don’t know that I care for Gavin’s suggested way, but
I think it would be nicer to have a single method for determining
the methods available to a class and then filtering on this. The
existing method methods would be specialised calls to these.
#methods(filter_conditions = :all, recursion_depth = 0)
Thus, if I wanted the public cliass methods for this class and its
immediate parent, I could call the existing method, or I could set
up my own filter:
#methods([:public, :class], 1)
I’m not sure if the filter conditions or the recursion depth should
be first, but I think that this is overall a good idea.
-austin
– Austin Ziegler, austin@halostatue.ca on 2003.05.08 at 08:49:32
···
On Thu, 8 May 2003 10:46:43 +0900, Yukihiro Matsumoto wrote:
Gavin Sinclair gsinclair@soyabean.com.au writes:
How about a single method “methods” that takes arguments:
methods(:instance)
methods(:private, :instance)
methods(:public, :class)
methods(:singleton)
etc.
I don’t feel dispatching features by argument is good idea.