Trans schrieb:
>Pit Capitain wrote:
>>Trans schrieb:
>>
>>>P.S. Anyone on why #nesting isn't in Kernel?
>>
>>Maybe because the only thing you can nest are modules, and the result is
>>a list of modules? IMO, it has nothing to do with general objects.
> 
> Actually that's my point. What you say is the common general thought,
> it's exactly what I had thought, but it's isn't true. #nesting actually
> has nothing to do with it's reciever 'class Module'.

Seems I can't express my thoughts very well. I know that Module.nesting 
isn't an instance method of Module and that you can't ask an instance of 
Module for its nesting.

What I wanted to say is that the value of Module.nesting depends only on 
the nesting of module definitions. It only matters in which (lexical) 
module context it is called. It has nothing to do with other objects. If 
you'd remove the class Module from Ruby, a nesting method wouldn't make 
sense anymore.

> And has more do
> with the object, namely, the nesting from _that place in the object_,
> well, at least as much as __LINE__ and __FILE__ do. By analogy, we
> don't use 'File.__LINE__'. Do you see what I'm getting at?

Yes, but you could remove the class File from Ruby and it would still 
make sense to get the name of the current source file. The current 
source file is a property of the compile time environment and has 
nothing to do with any Ruby language constructs. From this point of view 
it wouldn't make sense to associate __FILE__ with the Ruby class File.

> Kernel is not so much a mixin of Object, as it is a omni-accessible
> toolchest for the Ruby coder.

But __FILE__ is a token recognized by the parser. It is neither a 
constant nor a method of any module, including Kernel.

As always just my 2 cents.

Regards,
Pit