"Ara.T.Howard" <Ara.T.Howard / noaa.gov> writes:

> On Thu, 28 Jul 2005, Daniel Brockman wrote:
>
>> "Ara.T.Howard" <Ara.T.Howard / noaa.gov> writes:
>>
>>>> That is a reasonable belief.  Indeed, I'm not completely
>>>> sure myself that unification would reduce net confusion.
>>>> So I'd be interested in seeing some arguments.
>>>
>>> well - classes can't [extend objects] [...]
>>
>> Is that an argument in favor of unifying them?
>
> i don't think so.  the reason is that if classes could
> extend objects we'd have a real issue with
> ancestors/inheritence.  what i mean is that if one could
>
>    class A
>    end
>    class B
>      include A
>    end
>
> and this were the 'same' as
>
>    class B < A
>    end
>
> then that __would__ be confusing since including multiple
> classes would imply multiple inheritence.

And how is that confusing?  It's exactly what currently
happens when you include multiple modules.

   module A ; end
   module B ; end

   class C
     include A
     include B
   end

   C.new.is_a? A #=> true
   C.new.is_a? B #=> true

> if it did not imply multiple inheritence would the only
> difference be that one (B < A) made b.is_a?(A) true while
> the other (B.include A) did not -

I don't see how this could ever make sense.

> even though, for all intents and purposes they could do
> all the same things.  this seems broken and confusing
> either way - tough i'll admit the idea is interesting...

The version that doesn't have B.include(A) imply b.is_a?(A)
does seem broken and confusing, but is a straw man.

>> I agree.  My point is that Ruby's classes and modules are
>> very much alike.
>
> execept - and this is important - wrt inheritence.

How so?

>> were very much alike, I'd be in favor of unifying them.
>> But since the two pointer types are not alike at all,
>> your analogy doesn't apply.
>
> and i'm saying they are not that much alike because on
> this crucial difference.

See above.

>> Documentation in always nice, but I'm afraid the quality
>> of the documentation is irrelevant to the discussion
>> at hand.
>
> requiring people to understand the language fully,
> regardless of what that takes, before attempting to change
> it is never really irrelevant is it?

If anything I said in this thread was out of ignorance, I
apologize for my arrogance.  However, I would appreciate it
if you would point any such errors out.

>>> not everything can be intuitive AND powerful.
>>
>> But realize that what I'm saying is that Ruby is *not*
>> more powerful with classes and modules separate than it
>> would be with them unified.  I'm saying that Ruby would
>> be equally powerful (nay, more powerful) after
>> the unification.
>
> well - if you can work out how inheritence would work out
> - then maybe.

But inheritance would work exactly the same as it does now.

> realize that i'm one of those people that think that
> normal hackers cannot handle multiple inheritence anyhow
> and that, at the very least, it's an idea far less
> powerfull than mixins.

How is multiple inheritance far less powerful than mixins?

(I actually consider Ruby's mixins to *be* a kind of
multiple inheritance, but I'll play along for a while.)

-- 
Daniel Brockman <daniel / brockman.se>

    So really, we all have to ask ourselves:
    Am I waiting for RMS to do this?   --TTN.