Re: Clean Object Class Design -- Circle/Ellipse
Date: Sun, 19 Aug 2001 18:21:27 GMT
Message-ID: <3b7fd1af.3739650192_at_news.grpvine1.tx.home.com>
On Sun, 19 Aug 2001 00:01:55 -0400, "Bob Badour" <bbadour_at_golden.net> wrote:
>Marc Gluch wrote:
>>Axioms of a theory are expressed in terms of primitives of that theory
>The primitives of the subtype/supertype relationship between Real and
>Integer are Real and Integer.
Before you can consider whether one type is a subtype of another,
you have to define each type (specify its semantics).
If you don't do that, you are talking about words as strings of
characters, with no meaning.
Only when you have the specs, you can analyze them to determine if they have the properties that satisfy whatever your definition of subtype is.
The standard mathematical definition of integers does not involve rationals, or reals (for some odd reason mathematicians think that closure and simplicity are important).
Would you argue that circles are spheres, because x^2 + y^2 + z^2 = r^2 reduces to x^2 + y^2 = r^2 when z= 0?
>>BTW, you still didn't answer the question of utility of such
>>definition.
>
>You didn't answer the question of the utility of Stroustrup's original essay
>on the topic.
You din't ask.
BTW, which original essay of Stroustrup are you talking about?
The only one referenced in Date's article (surely email =/= essay) is
THE C++ PROGRAMMING LANGUAGE.
Its utility is in describing syntax, semantics and applications of a
programming language, which is NOT
" conspicuous by its absence in the industry at large".
In other words, its wide-spread usage demonstrates
the utility of C++ and its inheritance model.
>If the ( Date's?) definition has no utility,
>Stroustrup would have no reason to even address it.
Yes, he would - politeness.
Stroustrup only responded (with best intentions) to Date's email.
I don't think he anticipated how much his words would be twisted
by Date (and you).
Date himself admits: "with hindsight, some of those comments might
have been regarded as gratuitously offensive. (...) I've toned down
some of my criticisms, (...), to say it again, the article is not
meant to be ad hominem"
Perhaps it's not meant to but it remains so nontheless.
Before you call my assesment of the article ad hominem again, try showing that:
- Date is not confused when he counters Stroustrup's "[Entities] called "circle" and "ellipse" are quite common in drawing programs and in interactive systems dealing with on-screen representations of a wide variety of entities. These entities can reasonably be called "circle" and "ellipse" because their shapes follow the standard mathematical definitions. However, they typically have additional properties (such as color and associated text) and operations " with: "I strongly disagree with the suggestion that, for example, the combination of a circle and a color is a circle. The former is an ordered pair of values of the form <circle,color>, the second is a singleton value of the form circle.(...) To say a circle is a colored circle is like saying a slice of bread is a sandwich."
Where did Stroustrup suggest combination, i.e composition (an ordered pair whether written as <circle, color> or circle x color is still a composition) to produce a colored circle? Where did he suggest that circle is a colored circle?
What Stroustrup suggested was (fairly obvious, though perhaps not to
you or Date) that
type CIRCLE
center: POINT; radius: REAL; color: COLOR; label: TEXT;
is a perfecty useful definition for a class of (drawing) applications.
It's not hard to guess that Stroustrup would subsequently observe
that label and color are also declared in other types such as
TRIANGLE, RECTANGLE, etc, and refactor common attributes (and
behaviors) to the supertype Shape (RenderableElement if you prefer).
Circle would inherit from RenderableElement, so CIRCLE's own
(local) definition would be confined to defining center and radius
(as it is in math). ELIPSE would also be derived from
RenderableElement, but CIRCLE would not be derived from
ELIPSE, because (ignoring different axiomatizations)
if you constrain CIRCLE constructor to
new CIRCLE(Point center, Real radius) {
super (center, radius, center, radius) }
you waste superclass's attributes
(mismatch of "logical structures", per the ISO "definition" of type).
b) that the inferitance model Date proposed is more useful than Stroustrup's inheritance model in a programming language.
Your turn now; utility of Date's defnition, please? Compare C++ (Stroustrup inheritance) to C+- (Date inheritance).
>Neither would any of the other major OO
>proponents who have tackled the issue.
Most people try to answer a question, when asked politely,
not in a rush, and when answering does not involve
unreasonable burden.
>All axiomatizations exist just as all values exist.
Unfortunately, most of them are inconsistent
>We need an abstraction of the device. We need abstractions of the
>tools for marking up the device. We need an abstraction for a renderable
>element.
>A renderable element has a position and size that the user can manipulate as
>well as a polymorphic scalable image. I decorate any shape with a pen for
>drawing its outline. I decorate any closed shape with a brush for filling
>its interior. The brush could specify a solid color, a hatched color, a
>bitmap or transparency etc.
You traded color for pen (and/or brush). No matter how you try,
the RenderableElement (Shape?) will have some
"non-geometric" attributes.
>Are you now claiming that CwWidget is a circle value?
Playing a word game? In programming names don't mean anything
until given interpretation.
I claim that in graphics applications color is a perfectly acceptable
attribute of the objects being graphed, regardless of whetther they
are called widgets, circles, or any other names. When some subtype
of RenderableElement has a center and a radius, you might as well call
it CIRCLE (BTW, that name will only show up in the scope of the
package in which it was defined). Of course, in C++ you can also
define CIRCLE in a different package, and using multiple inheritance
you can derive RenderableCircle from RenderableElement and Circle
for drawing purposes. It won't change the fact that circles with color
are still circles and not otherwise.
Whether you define color directly in Shape, or delegate to Brush is a design decision completely dependent on the needs of the application (as perceived by the designer). The consequence of using Brush is that now you either need a separate Brush for each instance of Shape, or you have to remember which color was used to draw each shape somewhere else (unless you don't need the ability to move the shapes around on the canvas, once drawn).
Marc Gluch
Mindtap Inc.
Received on Sun Aug 19 2001 - 20:21:27 CEST