On Thu, 28 Jul 2005, Daniel Brockman wrote:

> As has been pointed out countless times already, the diamond inheritance
> problem already exists in Ruby:
>
>   module A
>     def initialize(val)
>       @var = val
>     end
>   end
>
>   module B
>     include A
>     def initialize
>       super(5)
>     end
>   end
>
>   module C
>     include A
>     def initialize
>       super(42)
>     end
>   end
>
>   class D
>     include B
>     include C
>   end


did you run this?  this is most defintely __not__ the diamond problem - it is
strictly a tree:

   harp:~ > cat a.rb
   module A
     def initialize(val)
       p 'in A'
       @var = val
     end
   end

   module B
     include A
     def initialize(*a)
       p 'in B'
       super(5)
     end
   end

   module C
     include A
     def initialize(*a)
       p 'in C'
       super(42)
     end
   end

   class D
     include B
   end

   p D::new

   class D
     include C
   end

   p D::new


   harp:~ > ruby a.rb
   "in B"
   "in A"
   #<D:0xb75ce160 @var=5>
   "in C"
   "in B"
   "in A"
   #<D:0xb75ce05c @var=5>

if this were the diamond problem ruby would have needed to choose between
__either__ the 'initialize' in B or C but, because we are walking a tree, it
simply does both - each 'include' statement is adding depth to the search but
it never becomes a complex graph that needs an algorithim which resolves
conflicts.  see

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

for more on this.  again - there no ambiguity in which 'initialize' ruby calls
(both) and therefore no diamond problem.

hth.

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