From: "Ara.T.Howard" <Ara.T.Howard@...>
Date: 2005-07-28T05:05:01+09:00
Subject: Re: What's so special about operators, built-in classes and modules?

On Thu, 28 Jul 2005, Daniel Brockman wrote:

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

straw man!  i'm not that smart ;-)

i was doing too much at once.  all i was trying to say was that

   B < A

means inheritence.  if you also want to be able to

   class B
     include A
     include Z
   end

and have that also mean inheritecne - then multiple inheritence must be
addressed.  my point is simply that i don't think you can unify modules and
classes without also intrducing multiple inheritence - which is what matz's
comment about complex graphs was getting at...  (i think)

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

you can't currently do this

   http://en.wikipedia.org/wiki/Diamond_problem

with mixins.  if unification took place you could.

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

i didn't mean you - but people learning ruby.  improved docs could benefit
them.  sorry for confusion.

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

because people don't use it well - it's complexity precludes average
programers using it in the very situations where it could be most benefit..
just at it's prevelance in languages which support i and compare that to the
useage of mixins in ruby, for example.

mixins are powerful because they provide 90% of the functionality of mi with
10% of the debugging.  this is primarily because it's easy to affect the
method search tree.

interesting:

   http://64.233.167.104/search?q=cache:cSj6WP7jx2wJ:csl.ensm-douai.fr/research/uploads/nouryBouraqadi.esug2003ResearchTrack.pdf+mixin+vs+multiple+inheritence&hl=en

cheers.

-a
-- 
===============================================================================
| email :: ara [dot] t [dot] howard [at] noaa [dot] gov
| phone :: 303.497.6469
| My religion is very simple.  My religion is kindness.
| --Tenzin Gyatso
===============================================================================