[suby-talk] "Is" and ideas for moving foward

[Peter Vanbroekhoven]

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
>    ...
>  end

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
> level.
>
>  class X
>    class << self
>      include M
>    end
>  end
>
> 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
>> then?
>
> Well, they're like local vars. They are utility functions. But maybe
> you are right, maybe non-inheritable methods have no business being
> there.

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 
behavior.

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 
exception.

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
                               ^
                               |
                               s
                               |
   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 
is internally).

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

Peter