From: Mathieu Bouchard <matju@...>
Date: 2002-01-16T00:52:35+09:00
Subject: Re: a wishlist for ruby 2.0


On Tue, 15 Jan 2002, Yukihiro Matsumoto wrote:
> |* add Thread.granularity=(v:Float),.granularity->Float,
> |* add Thread#max_stack_size=(v:Fixnum),#max_stack_size->Fixnum.
> I think these two requires specific threading implementation (or at
> least API).  But I'm not sure it's possible (Windows thread has
> different model from pthread, right?)

Last time I checked, Ruby still had its own thread system. I don't know
what you mean.

> |* remove Module.constants, which currently calls Object.constants as
> |Module#constants on the Object object; doing that would uncover the other
> |Module.constants, that is, Module#constants on the Module object.
> This is to show constants defined in outer modules in nest.
> Maybe it can be implemented by private Kernel#constants, just like
> local_variables.

IMHO, it's certainly very bad that two methods with different meanings
have the same name in the same hierarchy. If you want to keep it, it
should at least be renamed.

> |* Module#included_modules(recurse=true) where
> |included_modules(false) would give a list of only _direct_ inclusions.
> |This is consistent with Module#instance_methods, except for the default
> |value.
> Maybe useful.

It's not "maybe useful", it's "very useful". This is necessary for correct
introspection. It answers to the question: which calls to Module#include
were made precisely in this object ? This is an information that Modules
keep verbatim anyway.

> |* Module#instance_methods(recurse=true,visibility=:default) where
> |visibility can also take values :public, :protected and :private.
> |Object.methods(recurse=true,visibility=:default) like the above, plus
> |recurse=false would fetch only singleton methods. remove all methods
> |obsoleted by those two extensions and make them emulated by
> |"ruby1-compat.rb".
> Why do you want to remove *_instance_methods?

I first want redundancy to be factored out, and then I want Ruby classes 
to stay quick to learn, even while new functionality is added. Making
visibility a parameter will allow future method-processing methods to be 
at once consistent with Ruby and non-redundant.

> |* add argument to load/require to specify the context of
> |evaluation, and add to load/require/eval a way to override the default
> |line-numbering.
> I'm not sure what you mean.

if I eval a ruby file which was unpacked from a .zip file, I'd like it to
say where it came from instead of "(eval)". (okay, it didn't have to do
precisely with _line numbering_. sorry)

> |* add File#open, that does like File.open, but on an existing file
> |handle. On open file, could raise exception or just close the file
> |automatically. change File.new so that with 0 arguments it creates a
> |closed File.
> I'm not sure what you mean.  What for?

I withdraw this suggestion.

________________________________________________________________
Mathieu Bouchard                   http://hostname.2y.net/~matju