Re: On Formal IS-A definition

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Thu, 06 May 2010 23:37:40 -0300
Message-ID: <4be37cf5$0$12455$9a566e8b_at_news.aliant.net>


David BL wrote:

> 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.

You mention imperative programs. Imperative programs are precisely those for which the only operations on variables are assignment and reference. The operations on the referenced values are operations on values not operations on variables.

Coercion has nothing to do with it.

> 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.

Exactly! Ellipse variables are a proper subset of circle variables. Received on Fri May 07 2010 - 04:37:40 CEST

Original text of this message