Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Module.nesting -> Kernel#nesting

Reply
Thread Tools

Module.nesting -> Kernel#nesting

 
 
Trans
Guest
Posts: n/a
 
      08-16-2005
I'm trying to write a little method called Module#modspace, which will
return the module/class a module/class is defined in. I.e.

Module X
Module Y
Module Z
end
end
end

X::Y::Z.modspace #=> X::Y


So I thought, Module.nesting would help do the trick. But I discovered
the Module.nesting returns the nesting according where it is called in
the code, nothing more. It is like __LINE__ or __FILE__ in this
respect. So it seems to me that it would be more appropriate to define
#nesting in Kernel, not as a class method of Module.

BTW, any help writing Module#modspace appreciated.

T.

 
Reply With Quote
 
 
 
 
Dale Martenson
Guest
Posts: n/a
 
      08-16-2005
---- Original message from Trans on 8/16/2005 2:36 PM:

>I'm trying to write a little method called Module#modspace, which will
>return the module/class a module/class is defined in. I.e.
>
> Module X
> Module Y
> Module Z
> end
> end
> end
>
> X::Y::Z.modspace #=> X::Y
>
>
>So I thought, Module.nesting would help do the trick. But I discovered
>the Module.nesting returns the nesting according where it is called in
>the code, nothing more. It is like __LINE__ or __FILE__ in this
>respect. So it seems to me that it would be more appropriate to define
>#nesting in Kernel, not as a class method of Module.
>
>
>
>

This is mostlikely not the best way to do it, but here is a way to get
at the information.

class Module
def lineage
eval self.ancestors.to_s.sub( /::[^:]$/, "" )
end
def modspace
lineage
end
end

module X
module Y
module Z
end
end
end

a = X::Y::Z

p a.modspace
p a.modspace.class




 
Reply With Quote
 
 
 
 
Joel VanderWerf
Guest
Posts: n/a
 
      08-16-2005
Dale Martenson wrote:
> class Module
> def lineage
> eval self.ancestors.to_s.sub( /::[^:]$/, "" )


You can use name.sub(...) instead of self.ancestors.to_s.sub(...), but
it's not much better.

--
vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407


 
Reply With Quote
 
Dale Martenson
Guest
Posts: n/a
 
      08-16-2005
---- Original message from Joel VanderWerf on 8/16/2005 5:04 PM:

>Dale Martenson wrote:
>
>
>>class Module
>> def lineage
>> eval self.ancestors.to_s.sub( /::[^:]$/, "" )
>>
>>

>
>You can use name.sub(...) instead of self.ancestors.to_s.sub(...), but
>it's not much better.
>
>
>

Actually, it is a lot better since you avoid cases where there are
additional includes. Module#ancestors
returns an array which causes problems with my original suggestion.

Example:

module X
include Math
module Y
include Comparable
module Z
include Enumerable
end
end
end

Thanks, Joel for your suggestion. For some reason, Module#name just
didn't come to mind.



 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      08-17-2005
Nice use of #eval. That's what I was missing. ( I usually try to avoid
#eval, but in this case it makes it much easier).

Thanks,
T.

P.S. Anyone on why #nesting isn't in Kernel?

 
Reply With Quote
 
Pit Capitain
Guest
Posts: n/a
 
      08-17-2005
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.

Regards,
Pit


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      08-17-2005

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'. 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?

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

T.

 
Reply With Quote
 
Pit Capitain
Guest
Posts: n/a
 
      08-17-2005
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


 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      09-15-2005
> But __FILE__ is a token recognized by the parser. It is neither a
> constant nor a method of any module, including Kernel.


True. But if you were to try to define it yourself it woul be a Kernel
module.

Anyway, I've come back to this old thread b/c I realize now, why
exactly this would be more approriate as a Kernel method and not a
Module method: the definition requires a "Binding.of_caller" in order
to work --ie. if one were to try to do it in ruby themselves. So
underthehood it must be doing the same. Since Binding.of_caller is
considered "not good" (do I understand correctly that matz has
declined this functionality for Ruby?) then this method goes against
that grain.

How did I realize this? I was trying to write an Ruby interpolate
method as a String module function. And for the same reason it was not
possible --I had to put it in Kernel.

T.

 
Reply With Quote
 
Trans
Guest
Posts: n/a
 
      09-16-2005

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

>
> True. But if you were to try to define it yourself it woul be a Kernel
> module.
>
> Anyway, I've come back to this old thread b/c I realize now, why
> exactly this would be more approriate as a Kernel method and not a
> Module method: the definition requires a "Binding.of_caller" in order
> to work --ie. if one were to try to do it in ruby themselves. So
> underthehood it must be doing the same. Since Binding.of_caller is
> considered "not good" (do I understand correctly that matz has
> declined this functionality for Ruby?) then this method goes against
> that grain.
>
> How did I realize this? I was trying to write an Ruby interpolate
> method as a String module function. And for the same reason it was not
> possible --I had to put it in Kernel.


Well, I'll correct myself. Techincally, you still need
Binding.of_caller using Kernel. It's just that Kernel's modus operandi
is functionality unversally present, so it seems like the right place.

T.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off




Advertisments