On Wed, 16 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.
> Ruby 1.x does.  But we're talking about Rite, right?

I see. Then .granularity= can't be done. But #max_stack_size= would have
an effect on the counter that you use for SystemStackError "stack level
too deep", not anything at the thread implementation level.

> |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.
> Name suggestion?

I don't know. Not sure why Module.constants is useful anyway.

> |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.
> I'm positive about this proposal.

Ok, but is that information really stored after all? I mean, because:

> 3. No for the third assert.  Unlike inheritance, "include" copies
>    module attributes into a class/module, so that even if the included
>    module (ModY) does include new module (ModX), it doesn't affect the
>    module (ModZ).  It's known restriction that would not be fixed in  
>    the near future.

I'm disappointed. (and this suggests that the list of directly included
modules is not kept, and instead the list of _all_ included modules is
kept, which somehow disallows #included_modules(false)).

> I sometimes prefer redundancy in methods names to adding a parameter.
> Parameters may increase orthogonality, which may cause combination
> explosion.

This is normally seen as a positive thing. After all, it distinguishes
language interpreters from other kinds of software.

> Do you mean you want to use the 3rd and 4th optional argument to eval?

exactly that. sorry. You can also say "RTFM" instead.

> |2. I don't know, but maybe yes.  I have to investigate more.
>
> pipe may not work on non-UNIX platforms.  We have to make sure before
> merging them in.

test for existence of either IO#pipe or TCPSocket, and if neither is
there, consider the test to be non-applicable. (Or do this only with
IO#pipe if for some reason TCPSocket must not be used.) I don't know
whether there are special provisions in Test::Unit to flag tests to be
non-applicable (in addition of Passed, Failed, Error)

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