SubTyping versus SubClassing
Vijay singh
I am not sure if SubTyping w.r.t SubClassing has been discussed here
before. But I remember Mr Lahman, in one of his post suggesting that
Subtyping was not discussed properly in OOAD books.
I was wondering if people would care to put their views on this topic.
Regards
Vijay
Universe
To start off not all subclassing generates subtypes. And that is true
in multiple ways on multiple levels. Not enuff time now to detail, more
later.
Elliott
--
Theory Leads, Practice Verifies
Profiteer US Out of Iraq Now!
Vijay singh
> vij_...@hotmail.com (Vijay singh) wrote:
>
> > Hi
> >
> > I am not sure if SubTyping w.r.t SubClassing has been discussed here
> > before. But I remember Mr Lahman, in one of his post suggesting that
> > Subtyping was not discussed properly in OOAD books.
> > I was wondering if people would care to put their views on this topic.
> >
> > Regards
> > Vijay
>
> To start off not all subclassing generates subtypes. And that is true
> in multiple ways on multiple levels. Not enuff time now to detail, more
> later.
>
> Elliott
So am I right in thinking that in Java OOPL inheriting a interface or
a abstract class is form of subtyping. Inherting a class is
subclassing?
Alfredo Novoa
> To start off not all subclassing generates subtypes.
Only inheritance by constraint generates subtypes.
None of the OO languages implement inheritance by constraint.
Regards
Alfredo Novoa
> I am not sure if SubTyping w.r.t SubClassing has been discussed here
> before. But I remember Mr Lahman, in one of his post suggesting that
> Subtyping was not discussed properly in OOAD books.
Subclassing is about code reuse, not about subtyping.
OO inheritance is not subtyping, it is more related to pointer based delegation.
Regards
Dmitry A. Kazakov
Ada does (in a limited way, though):
type Gender is (Male, Female);
type Employee (Sex : Gender) is record ...
subtype Boys is Employee (Male); -- Only for men
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Vijay singh
about Polymorphic behaviour?
>
> Regards
Universe
> alf...@ncs.es (Alfredo Novoa) wrote in message news:<e4330f45.04091...@posting.google.com>...
> > vij_...@hotmail.com (Vijay singh) wrote in message news:<90f0abe8.04091...@posting.google.com>...
> >
> > > I am not sure if SubTyping w.r.t SubClassing has been discussed here
> > > before. But I remember Mr Lahman, in one of his post suggesting that
> > > Subtyping was not discussed properly in OOAD books.
> > Subclassing is about code reuse, not about subtyping.
Subclassing is a MECHANISM capable of implementing BOTH subtyping, type,
code reuse, type specialization. Type specialization is the most
common kind of OO polymorphic type substitution.
> > OO inheritance is not subtyping, it is more related to pointer based delegation.
Inheritance which might take the form of subclassing is a MECHANISM
capable of implementing BOTH subtyping, type, code reuse, type
specialization.
> Can you explain this further please? Do you mean that Subtyping is
> about Polymorphic behaviour?
Answer and more later,
[Gotta go!]
Universe
In general one may have *substitutability* of classes in OO.
Polymorphism is the specific form of substitutability with the aim of
swapping related class types that do variations of the same role, or
related class methods that do variations of the same behaviour.
Typically even with polymorphism one does not focus upon having
"swapable" classes that are whatever subtype means, but "swapable"
classes that *** promise to fulfill the same contractual role.***
The class types meeting that criteria need not be a parent base class a
line of classes derived from one another. The "swapable" classes may be
parent base and co-equal siblings.
Notably not all classes derived from a parent are "sub" anything of the
parent (some take sub to mean a *subset*). In most cases derived
"swapable" classes *specialize* the behavior of the base class.
Specialization means that for example each member of a derived set of
sibling classes perform behavior specialized for a specific set of
commonly related yet variable circumstances.
Indeed specialized subclass derivation and inheritance where the
subclasses types fulfill the same contractual role with specialized
variations.
Elliott
--
"There’s no point in being grown up if you can’t be childish sometimes."
~ Doctor Who :- }
Universe
[TyPo]
> ...
> Typically even with polymorphism one does not focus upon having
> "swapable" classes that are whatever subtype means, but "swapable"
> classes that *** promise to fulfill the same contractual role.***
>
> The class types meeting that criteria need not be a parent base class a
> line of classes derived from one another. The "swapable" classes may be
> parent base and co-equal siblings.
> The class types meeting that criteria need not be a parent base class
*and*
Universe
Please, how do you define "subtype"? Please, what is "inheritance by
constraint"?
Elliott
--
dip refers to *abstract interfaces* a form class
abstraction. The opposite form is a concrete
implementation class abstraction.
H. S. Lahman
> I am not sure if SubTyping w.r.t SubClassing has been discussed here
> before. But I remember Mr Lahman, in one of his post suggesting that
> Subtyping was not discussed properly in OOAD books.
I think what I said was that classes and types are two different things,
hence subclassing is semantically different than subtyping. In OOA/D we
deal with a class system (except for knowledge attribute ADTs) but in
OOP that is mapped into a type system that is the equivalent 3GL
implementation mechanism. The mapping is unambiguous, but they abstract
quite different views (set membership vs. property access).
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions -- Put MDA to Work
http://www.pathfindermda.com
blog (under constr): http://pathfinderpeople.blogs.com/hslahman
(888)-OOA-PATH
Alfredo Novoa
> > None of the OO languages implement inheritance by constraint.
>
> Please, how do you define "subtype"?
Ony type is a subtype of another type if it has a subset of the values
of that tyle.
> Please, what is "inheritance by
> constraint"?
The value set of a subtype is a subset of the value set of a type.
For instance IntegerNumber is a subtype of RationalNumber or Square is
a subtype of Rectangle.
Regards
Alfredo Novoa
> about Polymorphic behaviour?
No, subtyping is about sets and subsets.
A type is a set of values and a set of operations.
A subtype has a subset of the values.
For instance we could define a type Circle as a subtype of the type
Ellipse, because all circles are ellipses but not all ellipses are
circles.
Regards
Alfredo Novoa
> Subclassing is a MECHANISM capable of implementing BOTH subtyping, type,
> code reuse, type specialization.
In other words, it is yet another OO fuzzy term.
> > > OO inheritance is not subtyping, it is more related to pointer based delegation.
>
> Inheritance which might take the form of subclassing is a MECHANISM
> capable of implementing BOTH subtyping, type, code reuse, type
> specialization.
In other words: inheritance is a fuzzy term and it may mean many things.
Regards
Alfredo Novoa
> > I think what I said was that classes and types are two different things,
>
> False! Here Lahman mythologizes and yet again mixes up genuine OO
> with his Shlaer+Mellor method notions of OO as "glorified relational
> Entity/Relational" modelling.
I agree with Lahman on this.
Types are sets of values and operations, but "class" may mean many
different things.
Type is a well defined term, and class is a very fuzzy and overloaded
term, so types and classes are different things, although class
sometimes means type.
> Any cursory read of references to nearly every OOPL would show that
> most type checking OOPLs treat classes as types. OOPLs treat classes
> as type abstractions.
If they are type abstractions then they are not types.
Classes may be also: entities, objects, implementations of types,
mechanisms, etc.
In OO you can use the words "object" and "class" for almost anything.
Regards
Dmitry A. Kazakov
> Universe <univ...@tAkEcovad.OuT.net> wrote in message news:<43nek0pn4d527k0nj...@4ax.com>...
>
>>> None of the OO languages implement inheritance by constraint.
>>
>> Please, how do you define "subtype"?
>
> Ony type is a subtype of another type if it has a subset of the values
> of that tyle.
What meaning has "[sub]set of values".
[to answer this question you have to define "value". It is not easy to do
as it might appear, especially without the notion of an abstract type.
Welcome to a vicious circle! Of course you can claim that value = memory
bit pattern, but clearly it would lead to nowhere.
Once you fix the definition, you will probably discover that your notion of
subtype is quite wrong. One should talk not about [sub]sets of values, but
about [surjective] mappings of values.]
>> Please, what is "inheritance by
>> constraint"?
>
> The value set of a subtype is a subset of the value set of a type.
>
> For instance IntegerNumber is a subtype of RationalNumber
The opposite (according to your [wrong] definition). Rational numbers are
ones having a representation as Q/R, where both Q and R are integers.
> or Square is a subtype of Rectangle.
It depends. If you mean in-methods of Rectangle, then yes to have for any
Square a rectangular counterpart is useful. But consider out-methods, for
which you'd better have a square for each rectangle, which is impossible.
----------
Subtypes are defined not as an ersatz for subsets, but for provability some
generalized statements about types. For substitutability, many would say.
For this purpose subset relation is too weak to convey anything useful.
Dmitry A. Kazakov
>> Can you explain this further please? Do you mean that Subtyping is
>> about Polymorphic behaviour?
>
> No, subtyping is about sets and subsets.
>
> A type is a set of values and a set of operations.
>
> A subtype has a subset of the values.
... without operations?
... with less operations?
... with same operations?
... with more operations?
... with other operations?
Alfredo Novoa
> [to answer this question you have to define "value".
An element of a set.
> It is not easy to do
> as it might appear, especially without the notion of an abstract type.
It is easy because a value is simply an element of a set.
> Welcome to a vicious circle! Of course you can claim that value = memory
> bit pattern, but clearly it would lead to nowhere.
I disagree, "value" is mathematical concept and it can't be defined as
a memory bit pattern.
> Once you fix the definition, you will probably discover that your notion of
> subtype is quite wrong.
How can I fix the definition?
My definition is the standard definition.
http://www.nist.gov/dads/HTML/abstractDataType.html
> One should talk not about [sub]sets of values, but
> about [surjective] mappings of values.]
How do you define "mapping".
But you are using the word "value" again.
> Rational numbers are
> ones having a representation as Q/R, where both Q and R are integers.
Rational numbers are ones that can be expressed as a fraction where p
and q are integers and q <> 0.
Rational numbers with q = 1 are also integer numbers.
BTW rational numbers are a subset of real numbers.
> > or Square is a subtype of Rectangle.
>
> It depends. If you mean in-methods of Rectangle, then yes to have for any
> Square a rectangular counterpart is useful. But consider out-methods, for
> which you'd better have a square for each rectangle, which is impossible.
No, you have a rectangle for each square. If you have 10 squares you
have at least 10 rectangles.
Regards
Dmitry A. Kazakov
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message news:<tur21vlxh26i$.1o30kblq...@40tude.net>...
>
>> [to answer this question you have to define "value".
>
> An element of a set.
Any element of any set? Values used in programs represent an immeasurably
small subset of ones used in mathematics.
>> It is not easy to do
>> as it might appear, especially without the notion of an abstract type.
>
> It is easy because a value is simply an element of a set.
Then you have to have sets before values. OK, what is a set of values? Your
statement above defines neither set nor value.
>> Welcome to a vicious circle! Of course you can claim that value = memory
>> bit pattern, but clearly it would lead to nowhere.
>
> I disagree, "value" is mathematical concept and it can't be defined as
> a memory bit pattern.
You cannot use mathematical values as-is, to describe types appearing in
programming. You have to limit them. This is equivalent to define the term
"value".
>> Once you fix the definition, you will probably discover that your notion of
>> subtype is quite wrong.
>
> How can I fix the definition?
>
> My definition is the standard definition.
>
> http://www.nist.gov/dads/HTML/abstractDataType.html
It reads "A set of data values and associated operations that are precisely
specified independent of any particular implementation". Note
implementation independence. This implies my these: we have to talk about
mappings rather than about singular objects. This is also the standard way
used in mathematics. When for example, real numbers (R) are constructed
using say, Dedekind's sections, nobody cares that technically R is not a
superset of N (natural numbers). Implementation is no matter, there is a
mapping N->R, which is all we need.
>> One should talk not about [sub]sets of values, but
>> about [surjective] mappings of values.]
>
> How do you define "mapping".
A function, a set of ordered pairs.
> But you are using the word "value" again.
Yes, but I do not need to study them. When you say that A is a subset of B,
then you are bound to "any member of A is a member of B". You have that
nasty "is a". How to check if x "is" y? By memory address? By memory
content? By calling operator "="? See, we are sinking in implementation
details. With mappings we only claim that we know a way to find for some x
of A some y in B. We won't tell which way, of course! (:-))
>> Rational numbers are
>> ones having a representation as Q/R, where both Q and R are integers.
>
> Rational numbers are ones that can be expressed as a fraction where p
> and q are integers and q <> 0.
>
> Rational numbers with q = 1 are also integer numbers.
>
> BTW rational numbers are a subset of real numbers.
See above.
>>> or Square is a subtype of Rectangle.
>>
>> It depends. If you mean in-methods of Rectangle, then yes to have for any
>> Square a rectangular counterpart is useful. But consider out-methods, for
>> which you'd better have a square for each rectangle, which is impossible.
>
> No, you have a rectangle for each square. If you have 10 squares you
> have at least 10 rectangles.
But it is not what I need for out-methods. Namely, to prove theorems with
the quantor "exists".
For example: for all height, all width exists rectangle of that height and
width. Substitute square there and it will be wrong. So this theorem does
not hold though each geometric square is a rectangle.
It shows that to have the domain a subset is just too weak for our needs,
if we would define subtypes in this way. The reason is that you forgot
about *operations*. Anyway, what for are values if I can do nothing with
them? Operations defined on the types are that theorems we have to prove
when we claim that A is a subtype of B. I.e. a subtype A *inherits*
operations of B. Note what happens with values is an implementation detail!
This is much stronger and useful than just to say that A inherits values of
B. LSP requires *all* theorems to be true, which is another pole to yours.
It is too strong to conform, alas. The truth lies, as always, in between.
Alfredo Novoa
> >
> > An element of a set.
>
> Any element of any set?
Indeed.
> Values used in programs represent an immeasurably
> small subset of ones used in mathematics.
So what? We are talking about the model, not about the implementation.
> > It is easy because a value is simply an element of a set.
>
> Then you have to have sets before values. OK, what is a set of values?
A set is an unordered collection of objects in which the elements
appear only once.
> Your
> statement above defines neither set nor value.
It defines value and not set because I was defining value and not set.
> > I disagree, "value" is mathematical concept and it can't be defined as
> > a memory bit pattern.
>
> You cannot use mathematical values as-is, to describe types appearing in
> programming. You have to limit them. This is equivalent to define the term
> "value".
I disagree. The types appearing in programming models are the same
types as in maths.
> It reads "A set of data values and associated operations that are precisely
> specified independent of any particular implementation". Note
> implementation independence.
It means that we are talking about models and not about
implementations.
> This implies my these: we have to talk about
> mappings rather than about singular objects.
No! We can talk about we want, and I am talking about models.
> Yes, but I do not need to study them. When you say that A is a subset of B,
> then you are bound to "any member of A is a member of B". You have that
> nasty "is a". How to check if x "is" y? By memory address?
It is irrelevant to the discussion.
> > No, you have a rectangle for each square. If you have 10 squares you
> > have at least 10 rectangles.
>
> For example: for all height, all width exists rectangle of that height and
> width. Substitute square there and it will be wrong.
Because it is an incorrect substitution.
> It shows that to have the domain a subset is just too weak for our needs,
> if we would define subtypes in this way. The reason is that you forgot
> about *operations*.
I didn't forgot that, but you are trying to apply operations when they
are not defined.
> when we claim that A is a subtype of B. I.e. a subtype A *inherits*
> operations of B.
But not all operations.
> This is much stronger and useful than just to say that A inherits values of
> B.
Inheritance is a fuzzy term. And your model is not what is generally
known as subtyping.
> LSP requires *all* theorems to be true, which is another pole to yours.
LSP is flawed.
Regards
Dmitry A. Kazakov
>>>> [to answer this question you have to define "value".
>>>
>>> An element of a set.
>>
>> Any element of any set?
>
> Indeed.
>
>> Values used in programs represent an immeasurably
>> small subset of ones used in mathematics.
>
> So what? We are talking about the model, not about the implementation.
I do not follow you, are you going to discuss the set theory?
>>> It is easy because a value is simply an element of a set.
>>
>> Then you have to have sets before values. OK, what is a set of values?
>
> A set is an unordered collection of objects in which the elements
> appear only once.
Using the word "collection" instead of "set", "object" instead of "value",
changes nothing. Take the set theory, arithmetic, higher algebra, what else
part of mathematics for granted.
>> Your
>> statement above defines neither set nor value.
>
> It defines value and not set because I was defining value and not set.
>
>>> I disagree, "value" is mathematical concept and it can't be defined as
>>> a memory bit pattern.
>>
>> You cannot use mathematical values as-is, to describe types appearing in
>> programming. You have to limit them. This is equivalent to define the term
>> "value".
>
> I disagree. The types appearing in programming models are the same
> types as in maths.
Which types? Are you talking about Russel-Whitehead type theory?
>> It reads "A set of data values and associated operations that are precisely
>> specified independent of any particular implementation". Note
>> implementation independence.
>
> It means that we are talking about models and not about
> implementations.
>
>> This implies my these: we have to talk about
>> mappings rather than about singular objects.
>
> No! We can talk about we want, and I am talking about models.
>
>> Yes, but I do not need to study them. When you say that A is a subset of B,
>> then you are bound to "any member of A is a member of B". You have that
>> nasty "is a". How to check if x "is" y? By memory address?
>
> It is irrelevant to the discussion.
OK, I am out of arguments...
>>> No, you have a rectangle for each square. If you have 10 squares you
>>> have at least 10 rectangles.
>>
>> For example: for all height, all width exists rectangle of that height and
>> width. Substitute square there and it will be wrong.
>
> Because it is an incorrect substitution.
It is equivalent. Subtype <=> substitutable. When there are incorrect
substitutions, then there is a problem.
Or maybe, people talking about subtypes just out of curiosity?
>> It shows that to have the domain a subset is just too weak for our needs,
>> if we would define subtypes in this way. The reason is that you forgot
>> about *operations*.
>
> I didn't forgot that, but you are trying to apply operations when they
> are not defined.
>
>> when we claim that A is a subtype of B. I.e. a subtype A *inherits*
>> operations of B.
>
> But not all operations.
>
>> This is much stronger and useful than just to say that A inherits values of
>> B.
>
> Inheritance is a fuzzy term. And your model is not what is generally
> known as subtyping.
Neither is yours. I bet, at least 80% people here in comp.object would
equalize subtyping and LSP-subtyping. Not that I belong to that 80%, just
as a statistical fact.
As for a model based of mappings, it is more general than both yours and
LSP. Use equality as the mapping and it becomes yours.
BTW, a model equivalent to yours was successfully used in Ada 83. It
defined subtypes exactly as constrained types. For example:
type Short is range -100..100;
subtype Positive_Short is Short_Integer range 1..100;
It is very useful and simple way to define new types. But as the history
shown, it is not the only one, and it is too weak for many purposes. So
today Ada 95 has a richer model.
>> LSP requires *all* theorems to be true, which is another pole to yours.
>
> LSP is flawed.
Yes, but your definition isn't better. To summarize its problems:
1. It is bound to the implementation issues requiring values of the subtype
to be "physically" same. [Unfortunately you refused to define what does it
mean to be same for values, but at first glance, int cannot become a
subtype of double, because 1 is not 1.0. At the same time, with some
imagination, void* could be a subtype of int, which is broadly used in our
beloved Windows API (:-))]
2. It tells nothing about substitutability. Equivalently, it tells nothing
about which operations the subtype will have, and so which operations of
the base type will be applicable to the values of the subtype. [In Ada 83
it was "solved" by allowing Constraint_Error to be raised everywhere.]
Mark Nicholls
> >> as it might appear, especially without the notion of an abstract type.
> >
> > It is easy because a value is simply an element of a set.
>
> Then you have to have sets before values. OK, what is a set of values? Your
> statement above defines neither set nor value.
>
I know nothing about formal type theory, but I am becoming more
interested in it, but my limited maths tells me that...."Then you have
to have sets before values".....is a very true statement.
and is exactly the case....you start with the the empty set (and the
axioms of set theory) and some sort of 'increment' operation like the
set of the set plus the empty set....it isn't that....but something
like it....and thus you create something isomorphic to the positive
integers.....then you create some other mapping that completely
escapes me, and get the set of integers...then the rationals etc
etc......
Is this not the case in the type theory world?
Dmitry A. Kazakov
>>>> It is not easy to do
>>>> as it might appear, especially without the notion of an abstract type.
>>>
>>> It is easy because a value is simply an element of a set.
>>
>> Then you have to have sets before values. OK, what is a set of values? Your
>> statement above defines neither set nor value.
>
> I know nothing about formal type theory, but I am becoming more
> interested in it, but my limited maths tells me that...."Then you have
> to have sets before values".....is a very true statement.
Yes, technically you need only the empty set for the Big Bang...
> and is exactly the case....you start with the the empty set (and the
> axioms of set theory) and some sort of 'increment' operation like the
> set of the set plus the empty set....it isn't that....but something
> like it....and thus you create something isomorphic to the positive
> integers.....then you create some other mapping that completely
> escapes me, and get the set of integers...then the rationals etc
> etc......
>
> Is this not the case in the type theory world?
In my world it is so. No matter how an when values appear, I need not to
look into them.
As far as I see, in Alfredo's world there should be a problem, because he
talks about subsets. So he need to start from the very bottom, present all
values, and only then to divide them into types.
P.S. Sorry for a late answer, just returned from a conference
Mark Nicholls
> >>>> as it might appear, especially without the notion of an abstract
type.
> >>>
> >>> It is easy because a value is simply an element of a set.
> >>
> >> Then you have to have sets before values. OK, what is a set of values?
Your
> >> statement above defines neither set nor value.
> >
> > I know nothing about formal type theory, but I am becoming more
> > interested in it, but my limited maths tells me that...."Then you have
> > to have sets before values".....is a very true statement.
>
> Yes, technically you need only the empty set for the Big Bang...
>
> > and is exactly the case....you start with the the empty set (and the
> > axioms of set theory) and some sort of 'increment' operation like the
> > set of the set plus the empty set....it isn't that....but something
> > like it....and thus you create something isomorphic to the positive
> > integers.....then you create some other mapping that completely
> > escapes me, and get the set of integers...then the rationals etc
> > etc......
> >
> > Is this not the case in the type theory world?
>
> In my world it is so. No matter how an when values appear, I need not to
> look into them.
>
> As far as I see, in Alfredo's world there should be a problem, because he
> talks about subsets. So he need to start from the very bottom, present all
> values, and only then to divide them into types.
You've lost me, not because you haven't explained just because I'm too
ignorant of your world to comment.
It was an observation that you need sets to have groups/rings/fields and I
was suprised it would be different in type theory.
Give me a few months and I may be able to comment more constructively.
Regards also.
Universe
behaviors.
The "specific" is important in that a type is always guaranteed to
perform certain specific behaviors.
Concrete types are when the guaranteed behavior of an abstract type is
applied to other specified types.
Mark Nicholls
> Abstract types are a specific set of operations, a specific set of
> behaviors.
>
> The "specific" is important in that a type is always guaranteed to
> perform certain specific behaviors.
>
> Concrete types are when the guaranteed behavior of an abstract type is
> applied to other specified types.
>
please explain......or demonstrate...I don't disbelieve you....I just need
you to fill in the gaps to completely believe you.
Edward Berard
singh <vij_...@hotmail.com> wrote:
> I am not sure if SubTyping w.r.t SubClassing has been discussed here
> before. But I remember Mr Lahman, in one of his post suggesting that
> Subtyping was not discussed properly in OOAD books.
> I was wondering if people would care to put their views on this topic.
Vijay,
If you go to "Google Groups" and do a search on "comp.object" and
the words "subclass" and "subtype," you will see discussions on
subtypes with respect to subtyping going back to 1989.
Two representative postings to comp.object were:
From: Andreas Guendel (gue...@exunido.uucp)
Subject: Re: What is subtyping?
Newsgroups: comp.object
Date: 1989-11-02 04:16:21 PST
From: s...@inmet.inmet.com (s...@inmet.inmet.com)
Subject: Re: Types vs. Classes
Newsgroups: comp.object
Date: 1990-09-28 12:26:00 PST
One significant contributor to the problem, i.e., "improper"
discussions of subtyping, is the confusion between types and
classes. This problem is compounded when one attempts to
superimpose misconceptions regarding subclassing and
subtyping on top of this.
-- Ed
--
Edward V. Berard | Voice: (901) 309-1912
The Object Agency, L.L.C. | Fax: (901) 755-5622
2965 Cane Creek Drive | E-Mail: e...@toa.com
Germantown, Tennessee 38138 | WWW: http://www.toa.com
Universe
> Vijay singh <vij_...@hotmail.com> wrote:
> >
> > I am not sure if SubTyping w.r.t SubClassing has been discussed here
> > before. But I remember Mr Lahman, in one of his post suggesting that
> > Subtyping was not discussed properly in OOAD books.
> > I was wondering if people would care to put their views on this topic.
> ...
> If you go to "Google Groups" and do a search on "comp.object" and
> the words "subclass" and "subtype," you will see discussions on
> subtypes with respect to subtyping going back to 1989.
>
> Two representative postings to comp.object were:
I excerpted passages from both below, but 1st:
> One significant contributor to the problem, i.e., "improper"
> discussions of subtyping, is the confusion between types and
> classes. This problem is compounded when one attempts to
> superimpose misconceptions regarding subclassing and
> subtyping on top of this.
To me it seems ez to interpret Berard here as meaning that "classes"
should not be considered "types", or "subtypes".
However the 2 articles Berard refers to properly and clearly situate
"classes", as "types" and "subtypes".
> From: s...@inmet.inmet.com (s...@inmet.inmet.com)
> Subject: Re: Types vs. Classes
> Newsgroups: comp.object
> Date: 1990-09-28 12:26:00 PST
>
> One significant contributor to the problem, i.e., "improper"
> discussions of subtyping, is the confusion between types and
> classes. This problem is compounded when one attempts to
> superimpose misconceptions regarding subclassing and
> subtyping on top of this.
>>Actually, I think OOP languages tend to be a bit schizophrenic
>>about the term "class" already, since the term is used both
>>for parameters/references which may in fact refer to a value
>>in any subclass of the class, and to identify *the* class of a value (which
>>only makes sense if you use the interpretation suggested above
>>of "smallest class which contains the value").
>
>I've never seen a person refer to a variable as a class (which you seem
>to say) although one can constrain a variable/parameter/reference object
>to only contain or reference an instance of a specific class in some
>languages. With such mechanisms, the difference between a class and a type
>is admittedly blurred.
> I certainly didn't intend to equate a variable and a class (though
> I admit my wording could be interpreted that way). I meant
> to say that the term class is used when specifying the "type"
> of a pointer/reference, when, at least in C++, pointers/references
> may in fact refer to any value in that class *or* one of its subclasses.
> However, a variable in C++, when declared to be of a certain "class,"
> may *not* contain a value of a subclass (it's not "big enough" to do so).
> This is the "schizophrenia" to which I was referring.
>
> Using the proposed terminology, a variable in C++ has a single specified
> "type," whereas a pointer/reference refers to a "class" of types.
> The C++ "class" X is defined to comprise the "type" X plus all types derived
> directly or indirectly from X. When calling a virtual
> function given a pointer to a *class* X, the
> *type* of the pointed-to object determines which specific
> implementation of a virtual function is called.
> From: Andreas Guendel (gue...@exunido.uucp)
> Subject: Re: What is subtyping?
> Newsgroups: comp.object
> Date: 1989-11-02 04:16:21 PST
>
> > 2). Why would you want a subclass *not* be a subtype?
>
> I would never *want* a subclass *not* be a subtype, just contrary it
> is an important design criterion for subclasses to conform with their
> superclasses in type and semantics (to define the latter formally is
> not done satisfactory in an OO system, as far as I know, any comments?).
>
> Nevertheless, it turned out in practise, that a lot of subclasses are
> written only for implementation convinience and conceptually differ
> much from their superclasses. Thoses classes are not "acceptable in
> contexts expecting another type (class)" [Snyder] (i.e. their super-
> class). This can be detected by a type-checker if the subclass hides
> methods which do not belong to their concept or redefines methods with
> incompatible types of arguments or result. Otherwise it should be pos-
> sible to give a hint to the type-checker `this is only an implementaion
> subclass'.
>
> In a lot of other situations, a subclass is a conceptual extension of
> its superclass but is not exactly compatible in type. For those classes
> an advanced typing mechanism has to be found that allows to express or
> even detects the commonalities between their types and allows contexts
> to rely on the commonalities instead on the concrete types. See the very
> interesting paper
>
> "F-Bounded Quantification for Object-Oriented Programming" by Canning,
> Cook, Hill, Mitchell and Olthoff at the ACM Conf. on Functional Progr.
> and Computer Architecture, September, 1989.
>
> > 3). Why would you want a class *be* a subtype of a different class?
>
> If you have a couple of classes implementing similar concepts in quite
> different ways, they will often be no subclasses of each other. To
> express that they are "acceptable in contexts expecting another type
> (class)" [Snyder, again] (i.e. the type belonging to their common
> concept) the type-checker needs some help. One way is to construct an
> abstract class and add it to the superclasses list of each implemen-
> tation (obviously, you need multiple inheritance in your language for
> this solution). Another way is to decrease the junction between classes
> and types at all.
Elliott
--
Before you manage dependency, you should have an object
model network of key domain and use case entities that
are collaborating together to get BUSINESS, SCIENTIFIC,
ARTISTIC requirements *done*!
Something to by god manage in the first place!
Universe
> "Universe" <univ...@tAkEcovad.OuT.net> wrote in message
> news:fu29l01m69d8g1blp...@4ax.com...
> > Abstract types are a specific set of operations, a specific set of
> > behaviors.
> >
> > The "specific" is important in that a type is always guaranteed to
> > perform certain specific behaviors.
> >
> > Concrete types are when the guaranteed behavior of an abstract type is
> > applied to other specified types.
> >
>
> please explain......or demonstrate...I don't disbelieve you....I just need
> you to fill in the gaps to completely believe you.
Mainly that what really characterizes a type is *operation*. A type
becomes concrete when applied to specific things.
However operation is often a feature of specific things.
Perhaps, I should give the internal attribute specificity of a thing as
much weight as the operations of the thing. That is given some
operations seem tied to internal attribute.
Elliott
--
Those whom think Bush is a master at anti-terrorism,
have a dependency inversion--a la Stockholm syndrome.
Mark Nicholls
> > > > behaviors.
> > > >
> > > > The "specific" is important in that a type is always guaranteed to
> > > > perform certain specific behaviors.
> > > >
> > > > Concrete types are when the guaranteed behavior of an abstract type
is
> > > > applied to other specified types.
> > > >
> > >
> > > please explain......or demonstrate...I don't disbelieve you....I just
need
> > > you to fill in the gaps to completely believe you.
> >
> > Mainly that what really characterizes a type is *operation*. A type
> > becomes concrete when applied to specific things.
OK, operation and some sense that something will happen.
> >
> > However operation is often a feature of specific things.
hmmm.....maybe.....
> >
> > Perhaps, I should give the internal attribute specificity of a thing as
> > much weight as the operations of the thing. That is given some
> > operations seem tied to internal attribute.
nope....not with this.
>
> And type is a composite of both - specific operations on specific
> things.
maybe...my arm could be twisted....I'm sort of going the DbC route at the
moment.....though I know nothing about it as Meyer is still in the post.
so at the moment a type (to me) is informally a set of operations and some
guarentees about the behaviour of those, both defined as a contract , a
subtype is simply a contract that is >= to the base contract and thus is
substitutable in some sense.
now a concrete type.....does concrete simple imply the ability to
instantiate....or something more?
Does it imply a complete definition of behaviour (because one must exist
i.e. it's implementation) and we get hung up on the overloading of
implementation name and interface name in most OOP's and the concepts get
muddled together?
>
> But typically in computer science there is tendency to abstract
> operations as type and say we can have the operations work on
> different things.
this is probably where I am.
'naive'?..........probably, I seem to have a 'naive' view about lots of
things.
>
> Division works on integers and floats. Yet within the commonality
> there are specific differences based on the operands being integers or
> floats.
contract (division,integer) >= contract(division, abstract number)
contract (division,floats) >= contract(division, abstract number)
now to compare contract (division,floats) and contract (division,integer)
is difficult, in fact meaningless without refering to a common infimum
contract, in some ways one may be stronger and in others, the other
will....i.e. a partial order....but Meyer is still in the post...so this may
be complete verbal diarhea.
>
> And we do say integer and float respectively are different types, even
> with the same operations. Kind of gets to my "concrete types" are
> abstract operations on "specific" things.
are they not more specific contracts on a base.
> But this begs the question
> because are not "things" types? So we can go with some major types
> are composites of types--in this case:
> division operation type+a number type
maybe.....in some ways I haven't got a problem with this....I looked into
formal concept analysis/ontologies once, I don't pretend to have got much
further than page 10 , but was struck how it looked like cross products of
types like COM but unlike traditional OO.....I think I prefer making cross
products (i.e. composites) than 'extending' one type into another....it's
easier to see what's going on and you don't get nasty syntactical clashes.
>
> A predicate logic over an intension?
>
? If I understood that I would worry ?
> Please feel free to "toss in" and say whatever seems relevant.
can I include irrelevant drivel?
Oh, I already have......