From: Mathieu Bouchard <matju@...>
Date: 2001-06-27T03:57:52+09:00
Subject: [ruby-talk:16925] Re: Something strange with Ruby's inheritance mechanism


On Mon, 25 Jun 2001, Aleksei Guzev wrote:

> I'll help as soon as You call. I like C++ much more than Assembler :)))
> Pentium's Assembler differs from previous processors' versions in use of
> registers. Now one can use general purpose registers ( ax, bx, cx, etc )
> as index registers ( earlier only si and di were allowed ). This
> significantly shortens code and uses stack less agressively. But
> crossplatfom application should not use machine code, and Ruby should
> not too.

Those characteristics are those of 386 assembler. 486 and Pentium
assembler are very little different from 386 assembler. The big
differences lie in which instructions (or pattern of instructions) are the
fastest to execute (but that's not a language difference).

On Tue, 26 Jun 2001, Aleksei Guzev wrote:

> # > Ruby should provide a short-time development and therefore
> # > no type-checking.
> # Short-time development should mean no type-checking when it 
> # makes development shorter, and type-checking when it makes 
> # development shorter. There's a balance you have to get.

> Strong typing shortens development of large project involving large
> stuff. I use Ruby only to call huge complicated application written in
> strong-typed languages.

Well, I've not seen that. It seems to me that type-checking and
contract-checking are most useful for defining interfaces that are central
and implemented several (or many) times. For other interfaces the benefits
are lower. 

> The disadvantage of strong typing is vivid in MS MFC library. If one
> wishes instances of its  class CA be collected in a linked list, he
> needs derive CA from Cobject, but this implies defining of hash function
> for CA!
> Thus one has to write a hash function in order to add object to a linked
> list. And there are much more overhead.

That's not a disadvantage of type-checking, it's a disadvantage of not
providing a default. Try this:

class Object
	def hash; raise NotImplementedError; end
end

> # > Generally, classes are equal when they provide equal 
> # interfaces. Class 
> # > B is a subclass of A when it provides all the methods of A and some 
> # > methods in addition. "<" in Ruby is a shorthand allowing 

> # In Ruby, A == B means it's _the_ same class, and A < B means 
> # all objects that inherit from A also inherit from B, that is, 
> # the set of A objects is smaller than the set of B objects. 
> # Ruby provides "class A<B" as a notation consistent with Class#<.
> 
> I didn't say about Ruby but I said "generally"

Well you didn't say what "generally" it was.

In mathematics there's this idea called "partial ordering". This is when
you have values that are not always comparable, that is, a value is not
always one of (greater than, less than, equal to) another value. While
totally ordered sets can be put in a straight line (e.g. reals, integers),
the partially ordered sets organize into arbitrary loopless graphs.
Multiple inheritance relationships are a partially ordered set. 

Of course you could use characteristics of the classes to map the set of
classes onto the set of interfaces, and then use equality between
interfaces.

All this to say I don't know where you pulled your definition of a
(Class,=) relationship from. 

matju