Re: Implicit conversions for value subtyping
On Apr 22, 9:09 am, David Barrett-Lennard <davi...@iinet.net.au>
wrote:
On Apr 22, 3:35 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
And no
matter what definition you choose, if it allowed this to be a
"form of inheritance" I would argue that said definition is at
total odds with any common sense meaning of "inheritance".
I was thinking of it as "inheritance" in the following sense: Let a
data type mean a set of abstract values plus operators on those values
(using operator in an algebraic sense). The "behaviour" of a datatype
is only externally visible through those operators. Relating this
back to C++ code, assuming all operators are expressed as free
functions without in-out parameters, an implicit conversion between
two datatypes means that all the operators of one are available to the
other - because of value substitutability. I think it is reasonable
to call that "inheritance" treating the word as simply meaning that
"stuff" associated with one "thing" is automatically available to
another "thing". Anyway that was the only point I wanted to make! I
just looked for synonyms of "inherit" at synonym.com and the only
alternatives it gave me are "get" and "acquire".
What about all the numerous
other types we made add in future, are we now talking about
multiple inheritance?
In the sense of inheritance I described above, definitely!
Then as they say "Houston we have a problem" ;-) That is because
traditionally (and I personally haven't seen any exceptions to
this so I would tentatively say "universally") the "inheritance"
concept in both type theory and practical programming, is thought
of if not /defined/ as a partial ordering. And in that case we
have the antisymmetry law of partial order logic ie
x <: y AND y <: x IMPLIES x = y
where "<:" is "inherits from" So, if we take you view that it's
reasonable for (since you allow coercions define "inheritance")
Rect <: Square
Square <: Rect
then
Square = Rect
which is obviously false. So I just think it's very unwise from
a communication perspective to call '"stuff" associated with one
"thing" is automatically available to another "thing"' inheritance.
Other phrases such as convertible, compatible, associated, etc come
to mind. Perhaps there is a traditional word for it in algebraic
type theory but I can't recall.
Suppose I create a coercion from complex<int,int> to rectangle,
does complex<int,int> now "inherit" from rectangle? What if we
add a coercion from rectangle to complex<int,int>, does rectangle
no circularly inherit from complex?
That's just weird so I'm not sure what your point is here.
Geometric interpretation of complex is VERY common. And the
interpretation of a vector defining a corner of a rectangle
rooted at the origin is also VERY common. So I don't see why
you call this "weird". But this is a nit anyhow.
A better
example for me would be classes named Polar and Cartesian and we would
like implicit conversions in both directions. I haven't studied the
rules of implicit conversions for C++ to know whether such a thing
works in practise, but in principle I can't see any problems with
alternative representations of abstract values.
Sure you can define implicit conversion in both directions
(for user defined types anyhow).
BTW the conversions between polar and cartesian representations
involve cos, sin, sqrt, atan2 which are inexact for rational numbers
(including floats). That could mean we have an example of the
following assertion breaking which I find extremely unappealing:
T1 x;
T2 y = x;
assert(x == y);
This can fail if coercions aren't invertible and y is coerced in order
to perform comparison using T1::operator==. On that basis I would
reject implicit conversions between polar and cartesian
representations.
Meh, that's an implementation issue that can be solved in a
variety of ways.
I would hope that implicit conversions between datatypes satisfy
reasonable "laws" to make program correctness easy to reason about.
Unfortunately C++ doesn't give you a transitive closure of the
Well, unfortunately or fortunately depending on your viewpoint,
the standards committee decided that disallowing such transitive
closure was a "reasonable law" to help ensure correctness. Maybe
one of the members will comment. I vaguely recall this briefly
discussed in either D&E or ARM but I can't be asked to track that
reference down right now. (I need grep'able copies of my books LOL).
defined implicit conversions. Consider that we extend my previous
example with an additional type to represent an arbitrary
quadrilateral and we recognise that square value is-a rectangle value
is-a quadrilateral value.
*sigh* you keep forcing the "is-a" thinking in. Do you really see
is-a as a necessary concept? Even a particularly helpful one? Do
you not see any value in my suggestion to drop that hierarchical
thinking in favor of "flatter" relational thinking ie algebraic
type theory?
Not anywhere close in my mind. How would
such "inheritance" thinking or terminology even be useful?
In the case of square value isa rectangle value, it is useful in the
sense that it is a reminder that one doesn't necessarily need to
implement operators on square that have already been written for
rectangles. If one forgets that then one may end up writing more code
than needed (and the C++ compiler won't complain of course).
Is that it?? A useful reminder? Sorry, that seems quite a tiny
(if any) benefit to force "is-a" on to every (perhaps any)
analysis of syntax or concepts.
For example, it is far more useful to keep in mind that division
is not closed over integers than it is to sing "an integer is-a
rational" all day long. The first viewpoint emphasizes knowing
the algebra, the second knowing some shoe-horned "hierarchy".
Square inherits functions defined on rectangles but not
No it doesn't "inherit" the functions. Instead you have created
an algebra in which an implicit coercion makes syntax such as
width(square)
valid. Suppose I now declare and explicit function for square
int area ( Square s ) { return side(s) * side(s) ; }
would you now propose to say that I have "overridden the
inherited (from rectangle) area function"? That doesn't make
any bit of sense to me. "inheritance" has no place here.
I'm not sure why. I thought the "override" metaphor was quite a good
one. I would however say it's a very dangerous analogy because it
means something quite different to overrides of virtual methods in the
context of subclassing. However, on the other hand we are talking
Yes, that was careless. I was using "override" in the type theory
usage forgetting that it has a restricted meaning in C++.
about data types here and we know that subclassing is completely and
universally useless for data types so I would suggest that confusion
cannot occur for C++ programmers that properly understand datatypes.
Eh, I would rather just avoid words like "inheritance" for this
mechanism since it already has such a strong nearly universal
connotation of ordering that does not apply here.
I would say that such an "override" must not be allowed to change the
externally visible behaviour, but it can be useful to optimise
performance when the compiler is inadequate.
For any data types T1,T2 and unary operator foo I don't believe the
assertion below should be allowed to fail:
T1 x;
T2 y = x;
assert(foo(x) == foo(y));
"overrides" would need to respect that (for example).
Sure I agree there are common sense semantic axioms one should
respect which apply to types in general.
KHD
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]