Re: On Formal IS-A definition

On May 7, 7:18 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 7 mei, 01:13, David BL <davi..._at_iinet.net.au> wrote:
>
> > On May 6, 9:10 pm, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
>
> > There is no subtype relationship between ellipse variables and circle
> > variables (in either direction).
>
> Look for a (very old) post by Jan Hidders on this subject.
>
> Strange as it may seem, it explains very well what is actually meant
> by this weard claim that a variable can be considered as being a
> subtype of another variable.
>
> Even I understood it, at the time I was reading that particular post.

Ok, found it back in 2001. It depends on what is meant by "substitution". I agree that in a correct program already written one may replace any circle variable with an ellipse variable and nothing really changes. Of course the ellipse variable only ends up holding circle values in the context of that program.

For practical reasons I consider substitutability to have more to do with what type coercions are allowed during function.procedure calls in imperative programs.

However, more to the point, there is a sense in which the premise behind subtype = subset is violated. Even though I think it's odd, if we choose to treat variables as values (by considering a variable to be an address value within some address space), and we have two functions to read/write variables (aka dereferencing pointer or address values)

   read(address)
   write(address, value)

Then although we can consider the ellipse variables to have a superset of the functionality, it is not true that that they represent a subset in the address space. A procedure that expects to be passed circle address values may balk when given ellipse addresses instead.

So in the rule:

subtype = subset of values + superset of the operators

there is a sense in which only the second half is satisfied when considering the question of whether an ellipse variable is a subtype of a circle variable. Received on Fri May 07 2010 - 03:34:48 CEST