Newsgroups: comp.lang.c++,comp.object,comp.theory,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!cam-news-feed3.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!howland.erols.net!cs.utexas.edu!chi-news.cic.net!ftpbox!mothost.mot.com!schbbs!news
From: shang@corp.mot.com (David L. Shang)
Subject: Re: Opinions on Ellipse-Circle dilemma?
Reply-To: shang@corp.mot.com
Organization: MOTOROLA 
Date: Mon, 17 Feb 1997 16:25:04 GMT
Message-ID: <1997Feb17.162504.12353@schbbs.mot.com>
References: <3305BA8E.11B3@cruzio.com>
Sender: news@schbbs.mot.com (SCHBBS News Account)
Nntp-Posting-Host: 129.188.128.126
Lines: 52
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:248398 comp.object:61254 comp.theory:18014 comp.lang.smalltalk:51754

In article <3305BA8E.11B3@cruzio.com> "James A. (Jim) Sawyer" <jas@cruzio.com>  
writes:
> Ranjan Bagchi wrote:
> > 
> > It's how to model a system where one object (Specialized) is a
> > constrained version of another object (Generalized).  The point of the
> > exercise is to show that specialization-via-constraint ought not to be
> > modeled via a subclassing relationship.  That's a pretty interesting
> > result, IMO.
> > 
> 
> Exactly!  Subclassing models generalization-via-addition-and-relaxation.
> Yet it seems most people thrash about trying to use it backwards, i.e. 
> for specialization.  I don't know why, but it seems more natural, until
> you get frustrated enough to stand on your head and think again.
> 

I disagree. This definition of subclassing is rather confusing. How
can subclassing model a generalization via-addition-and-relaxation?!

A subclass never add things. Instead, it reveals things that are not
declared in its superclass. When we design a superclass, we must have
this in mind: things are not declared does not mean that the things do
not exisit.

There is little chance that a subclass should do relaxation. It is anti-
intuitive and illogic. Rare examples can be found in reality
to demonstrate a useful contravariance.

Subclass does restriction and specialization. But a subclass should not do
a restriction and specialization on fixed things that already declared
superclass.

A common mistake in class hiearacy is that we fix things too early in
a superclass to allow a subclass to do specialization. One of too-early
fixations is the signature and the precondition for a method input.
For example, we fix the food type to "AnyFood" in a method "eat" in
the "Animal" class too early, which is actually a wrong presumption.
When things should not be fixed, we should always use "virtualization":
virtualizing the type and precondition that cannot be fixed, and let it
expressed via a variable dependning on "selfclass" -- the actual type of
the owner object. This virtualization enables subclasses to do
specialization via binding or reconstraining of the virtual constraint,
which is actually a "secon-order constraint" and is type-safe.

David Shang
______________
Visit http://www.transframe.com/ at Research/TransframeLanguage
to find a soultion.



