[suby-talk] "Is" and ideas for moving foward
calamitas at advalvas.be
Tue Oct 4 15:28:19 EDT 2005
On Sun, 25 Sep 2005, TRANS wrote:
> With #is and #as and units.rb I start to feel as if Nano/Mega is
> becoming a ... dare I say it? ... a Framework.
It doesn't matter whether you dare say it, you already did :-)
> Right, I recall now why it is impossible: b/c of the way Ruby parses
> and b/c Ruby is dynamic. So Ruby can't be sure a method even exists
> until it is defined, yet it must be able to parse the code that calls
> that method even it hasn't been defined yet. Just as you mentioned
> before, Python has an advantage in this regard.
Er... Well, I don't know Puthon, but unless it has type declarations, it
doesn't quite help.
> Oh no, I don't intend that we get rid of singleton class, only that it
> be reduced to one level only --no scary door. The upshot is simply
> that modules always "extend self". It would be almost exactly as if
> one did this themselves whenever they used a module:
> module Foo
> extend self
And for classes?
> Well it's definately complicate. I've been using Ruby for years now
> and I still get confused. I may not be the smartest guy around, but it
> certainly needs something to either simplify or at least make the
> various levels explict. include vs extend isn;t the problem pers e.
> After all what does extend do? it includes a module at the singleton
> class X
> class << self
> include M
> The problem simply is the difference between including a module and
> inheriting a class --i.e. the class method aren't included. But I can
> see a use for that, so I just want to fix the problem while still
> allowing a way to do that.
I know, it's the difference between inheriting a class and including a
module that bothers me too.
>> Hmmm, maybe... Aren't classes and modules about inheritance? Question is
>> them: do the non-inheritable methods actually belong in a class or module
> Well, they're like local vars. They are utility functions. But maybe
> you are right, maybe non-inheritable methods have no business being
You see, but utility functions is a weird word as local methods would be
visible from the outside.
But perhaps I'm not so right. We're talking here about specific instances
of Class or Module. I mean, the fact that class methods are inherited in
subclasses is something extra. Normally, the singleton class of an object
is a direct subclass of the object's class. Except when that object is a
class, because a class' singleton class is a direct subclass of the
singleton class of its superclass. That's in my opinion exceptional
But let's say that for class methods you should have a choice of
inheritability. Then what's the defaults: inheritability of
non-inheritability? I'm just wondering what is needed most often. I've
never really encountered problems with class methods being inheritable.
Either I want them to inherit, so there is no problem. Or I don't want
them to inherit, but even if they do, I'm not calling these methods on the
subclasses, only on my own class, so there is no problem. I must say
though that the latter case is rather the rule, the former case the
As for how it would look underneath the hood, that's the picture you've
once drawn for me (although that was about private methods). So it would
look like this:
c1 --c--> LocalC1 --s--> GlobalC1 --s--> Class
c2 --c--> LocalC2 --s--> GlobalC1
At this point one must wonder though. This can actually be done in Ruby
now. When defining a class C1, define a GlobalC1 (or just C1) that is
intended to be subclasses, and a LocalC1 that is not intended to be
subclassed. I don't know if it would work for classes though; I think not.
But this raises the question of how explicit this is going to be. Do we
allow people to get hold of both LocalC1 and GlobalC1? If so, which is
returned when asked for C1 tout court? I think for meta-programming, it
would be nice if it were possible to return "the object containing the
non-inheritable methods". Could be a module, or class (no matter what it
> The last we discussed we had layed out that inheirtance hierarachy,
> which was interesting. I would say we were leaning toward a separate
> space, would you?
I think that's better. IMO, it allows cleaner separation.
> Arghh!!!!!!!!!!!!! I know they are private but had totally forgotten
> #instance_methods is an alias for #public_instance_methods. I was
> thinkning it returned all of them. Sigh. It's that kind of thing that
> kills me. I can't believe not one person bothered to tell me that on
> ruby-talk or ruby-core --I was so frustarated by it --and became
> rather confused. Well, thanks for finally removing my confusion.
Did I miss something on ruby-talk or ruby-core? I'm skipping a lot these
days; it's the only way I can keep up with the volume.
More information about the suby-talk