Re: The Diarthrognathus principle

<[email protected]> wrote:
	There is a question that trouble me about conversions:
	is it a way of introducing polymorphism?
	
Not in the sense of generic/parametric polymorphism, no.
In the sense of "ad hoc polymorphism", also known as overloading, yes.

	If there is a feature f(a:A) and a conversion from A to B then
	writing f(b) when b is of type B will it be allowed?
	
Other way around.  If there is a conversion from B to A then f(b)
will be allowed.
	
ECMA draft 8.8.1
    Rules on Call requires the number of actual arguments to be the same
    as the number of formal arguments, and the type of each actual argument
    to be compatilbe with (conform or convert to) the type of the formal
    argument at the same position in the list.

A sketch of an example:

    class A ...
    convert from_b({B})
    ...
    class B -- does not conform to A
    ...
    class C -- does not conform to A
    convert to_a: {A}
    ...
    class DEMO ...
    feature
       f(x: A) is ... 
    ...
    feature
       demo(b: B, c: C) is	
          do
             f(b)	-- does f(create {A}.from_b(b))
             f(c)	-- does f(c.to_a)
	  end
    ...          

A nice little maintenance problem here:
    File X is a valid working class text.
    File Y is another valid working class text.
    You remove a feature from Y which has NO explicit mention in X
    (e.g. grep doesn't find it, Emacs doesn't find it, ...)
    X now has a type error.

Invisible conversions are a feature of PL/I that was dropped as
having proven too dangerous in the Ada design; they are a feature
of C++ that was dropped in the Java design.  At a minimum, if you
are using a language that has this feature, you need tools that
explicitly tell you which hidden conversions are done where.