From: "Chr. Rippel" <chr_news@...>
Date: 2002-01-16T04:53:51+09:00
Subject: Re: a wishlist for ruby 2.0


"Mathieu Bouchard" <matju@sympatico.ca> wrote in
> On Tue, 15 Jan 2002, Yukihiro Matsumoto wrote:
....
> > |* 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.

I completely agree with you on this point. Also, since I am probably
stupid, I don't exactly see what problem is being solved - we aready
have absolute ``name_pathes''' - e.g.

  ::Object.constants

always returns constants visible at the ``outer_most level''. Furthermore,
I already have to call ::Module.constants just in case somebody has the
silly idea of defining nested Class/Module called ``Module''.

>
> > |* 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.

Hm, I sometime wish that some (or all) of these methods were iterators ...

....


/Christoph