Perhaps it does blur the lines of the term module
Module
Mod
Module is the Class Name that recent versions of Ruby respond to, Mod
is apparently an old synonym that is still in the Rdoc, but Ruby
doesn’t recognize it, it could be a mistake in the docs, but it could
also be an old alias…
irb(main):036:0> Mod.ancestors
NameError: uninitialized constant Mod
from (irb):36
from :0
irb(main):037:0> Module.ancestors
=> [Module, Object, Kernel]
singleton classes.
so you’d say it works as intended, I am not sure I like it because it
makes metaprogramming for singleton classes a tad more difficult.
However that is not the issue, the issue is “should this be
documented” or are we too much inside the guts of ruby?
It cost me some effort to figure out what the question really
was :), but I presume you’re wondering why the singleton class
doesn’t appear in the ancestor list. I don’t know the answer, but I
think the question is posed more clearly when the example is
constructed for the singleton class of an ordinary object.
class Foo; end
Bar = class < #<Class:#>
Bar.ancestors # => [Foo, Object, Kernel]
If I had to make a call, I would say that the documentation had
inadvertently omitted a very special case.
Regards, Morton
P.S. Why ‘puts ancestors.inspect’ instead of the simpler ‘p ancestors’?
#<Class:#Class:0xb7dfae50>
Returns a list of modules included in mod (including mod itself).
Is this an error in doc or in behavior?
It cost me some effort to figure out what the question really
was :), but I presume you’re wondering why the singleton class
I know in ruby I would say
assert didactic_skills.zero? #
doesn’t appear in the ancestor list. I don’t know the answer, but I
think the question is posed more clearly when the example is
constructed for the singleton class of an ordinary object.
class Foo; end
Bar = class < #<Class:#>
Bar.ancestors # => [Foo, Object, Kernel]
Sure thanks for adding this
If I had to make a call, I would say that the documentation had
inadvertently omitted a very special case.
Very probable given the code in class.c
Regards, Morton
P.S. Why ‘puts ancestors.inspect’ instead of the simpler ‘p ancestors’?
Because output is shorter and more readable. I often get bitten by
debugging output
puts ary1
puts ary2
Where the heck does ary2 start?
so I developed a reflex to use inspect for all kind of
debugging/demonstrating output.
I feel it is goo[df] practice.
If you’re expecting it to return true, it can’t. Everything in the
array is an instance, not the class itself.
Getting bitten by my didactic skills
John please have a look at Morton’s code, he was so kind to explain
what I am worried about much clearer.
That said maybe I can make things clearer myself:
irb(main):001:0> a = class A; ancestors end
=> [A, Object, Kernel]
irb(main):002:0> a.include? A
=> true
irb(main):003:0> B = Class::new
=> B
irb(main):004:0> Bsingle = class << B ; self end
=> #Class:B
irb(main):005:0> b = Bsingle.ancestors
=> [#Class:B, #Class:Object, Class, Module, Object, Kernel] #Ah too bad my patched Ruby, I gotta recompile, sorry, normally the
singletons are #not in ancestor, please execute the code yourself to
see the difference.
irb(main):006:0> b.include? Bsingle
=> true
so I developed a reflex to use inspect for all kind of
debugging/demonstrating output.
I feel it is goo[df] practice.
But isn’t ‘p ’ shorthand for ‘puts
().inspect’? If this is the case and AFAIK it is, then
you just need to develop a new reflex to use p.
Ah you said p, not puts, that’s quite clever…
LOL you are an eagle eye, but you are right of course.
Robert
And yes you can chose the f above
puts ary2
LOL you are an eagle eye, but you are right of course.
You see things; and you say Why?
But I dream things that never were; and I say Why not?
– George Bernard Shaw
Actually p is more like a short form for
puts object.inspect
Actually p is more like a short form for
puts object.inspect
I admit that’s more strictly accurate, but I find it very close to a
distinction without a difference since I can’t think of a case where
() doesn’t evaluate to an object.
I launched a discussion about this on Ruby-core. I think there were no
consensus on this at the time.
See ruby-core:9604. Tom closed the related bug, but maybe I should re-open
it since, as far as I remember, there has been no final conclusion.
Sylvain J.
Merci Sylvain
I do not want to argue with the wise guys if it is an error - I
clearly thought so but that is not important
But it really would have saved me an hour of debugging if the doc
stated clearly that singletons are not included. I thought this might
help others and as it took me 20s to vim the missing line into class.c
I do not want to argue with the wise guys if it is an error - I
clearly thought so but that is not important
But it really would have saved me an hour of debugging if the doc
stated clearly that singletons are not included. I thought this might
help others and as it took me 20s to vim the missing line into class.c
As far as I can tell, singleton classes aren’t mentioned in the doc.
The documentation borders on folklore.
Singletons as a means of implementing both individual instance, and
class behavior have a position like “the man behind the curtain” in
“The W.ard of OZ.” We’re really supposed to disregard them.
Coming from a background in Smalltalk, my preference would be if this
machinery were more visible and official, but Matz has his reasons for
not doing so. For one thing, not documenting it, and hiding it from
methods like ancestors and class makes it easier to tinker with as the
language evolves without “officially” breaking backward compatibility.
I’d surely love to read this but I constantly get a timeout at this link
Given the name of your box I am afraid that this URL comes from your
local name resolution, would you have a DNS name?
Thx in advance
Singletons as a means of implementing both individual instance, and
class behavior have a position like “the man behind the curtain” in
“The W.ard of OZ.” We’re really supposed to disregard them.
Coming from a background in Smalltalk, my preference would be if this
machinery were more visible and official, but Matz has his reasons for
not doing so. For one thing, not documenting it, and hiding it from
methods like ancestors and class makes it easier to tinker with as the
language evolves without “officially” breaking backward compatibility.
Does that mean that no one who’s ever used Smalltalk can ever think
that it’s right for Ruby to deviate from Smalltalk? I ask in a
humorous spirit – and also because it gives me an excuse to mention:
I think the singleton class has always had a somewhat equivocal
position. I tend to root for it being treated as a real class, if a
somewhat special-purposed one, since it is a real class (and neither
virtual nor meta). That could change, of course. Matz has always
described it as just the way that per-object behavior happens to be
implemented in Ruby – and a case could certainly be made that classes
are an odd choice for that, since, while there are no hard-and-fast
rules about it, the first things most of us probably think of are
instantiation and inheritance and such, none of which can happen with
a singleton class.
Kernel#singleton_class would help a lot… or #singleton_module, if it
goes in that direction
For some reason something in my server config messed up the workings
of ProxyPass reverse, and I was seeing the local hostname and port,
and forgot to check when I cut and pasted from my browser.
)
I ask in a