From: gabriele renzi <surrender_it@...>
Date: 2005-07-29T22:06:03+09:00
Subject: Re: What's so special about operators, built-in classes and modules?

Daniel Brockman ha scritto:
> gabriele renzi <surrender_it@remove-yahoo.it> writes:
> 
> 
>>>>Perhaps we are using the term "simple" in
>>>>different manner.
>>>
>>>That would certainly explain a few things.  All else being
>>>equal, I consider "fewer concepts" to imply "more simple".
>>>(All else would not be equal in this case, but in my mind
>>>very little would change.)
>>
>>The point is that once you introduce MI
> 
> 
> Once we introduce *unified* MI.
> 
> Face it:  We already have MI, in one form or another.
> 
> What about calling it "multiclass inheritance", or MCI?

ok, I won't mind about it :)


>>(which is a simpler concept than single-class-inheritance-
>>with-modules-mixed-in) you bring a lot of new concepts
>>with it, i.e.
>>
>>- repeated inheritance
> 
> 
> No. [ruby-talk:149932]

sorry, I disagree with Jim, even if that was an insightful reading.


Compare:
# yes I know it is a bad use case for inheritance,
# since you'd use a PersonData class
class Person
  def initialize(name, addr)
   @name,@addr = name, addr
  end
end

class SuperHero < Person
  def initialize(name)
   super pseudonomize(name), nil
  end
end

class Reporter < Person
  def initialize(name, addr, newspaper)
   super(name, addr)
   @newspaper=newspaper
  end
end

class KentPerson < SuperHero, Reporter
  def initalize
   super(Reporter, name, addr, 'globe')
   super(SuperHero, 'superman guy')
end

what would @addr be?

> 
>>- diamond inheritance
> 
> 
> No. [ruby-talk:149845]

sorry, I'm dumb and I don't understand.
What are you "no"-ing to? that message *is* about diamond inheritance.
thus the concept have to be explained and introduced.


> 
>>- more complex semantics for "super",
> 
> 
> Super would still call the next method.

sure, which one ? the one in the first superclass or the second?
What about choice? Think of super in python

> 
>>both in his class usage
> 
> 
> What is "his class usage"?

class Foo
  def to_s
  ..
  end
end

class Baz < Foo, String,
  def to_s
   super # which class gets called?
  end
end
> 
>>and for builtin overriding
> 
> 
> What is "builtin overriding"?

def p(x)
  super 'overriden: '+x.inspect
end

> 
> 
>>- how should the mwethod resolution work?
> 
> 
> As it does now, by linearizing depth-first.

ok


> 
>>  Should it have a fixed order
> 
> 
> Yes, for some values of "fixed".
> 
> 
>>  be user-updateable?
> 
> 
> Yes, for some values of "user-updateable".

sorry, I don't understand what you mean.
I think as "user-updateable" the case of having an @ancestor variable or 
something like that. Fixed would just leave an ancetors as it is now.
Ho would you merge this?

> 
>>  In one case it would be less useful, in the other you
>>  would need to add another concept
> 
> 
> No, we don't need any new concepts.

sorry, we already introduced a lot, imho. I guess we can agree to disagree.

> 
>>- ..the same for class functions, maybe
> 
> 
> Yes, as discussed elsewhere in this thread, singleton
> methods on modules are a problem, but a solution does not
> have to introduce any new concepts.  For example, one
> possible solution is to make modules behave in this regard
> as classes currently do.

I did'nt read this yet
> 
>>- maybe we could add a way to use a rename+select thing
>>  like in Eiffel,
> 
> 
> That sounds cool, and I'll probably be all for it.
> However, it is irrelevant to this discussion.

it is relevant as a new concept

> 
>>  but would it play nicely with ruby's dynamic nature?
> 
> 
> Why not?
> 

mh.. renaming and sdelection is done at compile time as some kind of 
"syntactic" thing, while in ruby we have definition as a runtime event.
I am frightened it may mess up.

> 
>>and probably some more things.
> 
> 
> Probably not.
> 
> 
>>Mind you, I agree that in a theoretical non-ruby language
>>MI would be nice ;)
> 
> 
> Are you thinking of any particular "theoretical
> non-ruby language"?


nope. Io, maybe?