Christopher Spottiswoode wrote: (01)
> You sure are heavy with experience! But with all due respect
> for it (and I do mean that, as I much enjoy reading you on it,
> and must also thank you for your Latin), (02)
Well, as I look at what I wrote, in typing 3 words of Latin, I managed
to misspell one of them. The adage is "divide et impera". So much for
displays of erudition. ;-) (03)
> let me assure you that
> your past experience is a poor guide to my post you quoted from
> below. There is, out there or in the past, absolutely no
> "active practice that corresponds to Christopher Spottiswoode's
> view". (04)
My apologies for the misinterpretation. And thank you for correcting
the record. (05)
> You see, I certainly wasn't recommending an approach such as
> those that have produced all those silos. For example, I was
> talking of subdomains _within_ workflows and other suchlike
> activities. That's at a much finer granularity than that of those pesky
> silos. And yes, I shall be showing how sub-ontologies work at that fine
> level, if done right, and how to help ensure they are done right. (06)
Well, I shall be happy to read your grand opus. (07)
> Then in your paragraph about the "special-widget" class, your
> example is even an excellent basis for my own major criticisms
> of presently conventional OO, as it is precisely one of those
> "island-classes" that the Classical Object Model tends to
> produce. (And that's without getting onto one of my other
> favourite criticisms of OO in its present manifestation, where I
> show how method overriding is banished in MACK.) So MACK-style
> OO too is completely different from what you're used to. (08)
We probably agree on much of this. I have always viewed
"object-oriented" as a style of programming, full stop. I regard
"object oriented X" for all other X as re-learning principles from other
disciplines and re-titling them with "object-oriented" terms, and
sometimes misconstruing or mis-constraining them in the process. I have
learned to use OO terminology in order to communicate with most of the
software engineering community for the last 20 years. But I adhere to a
different modeling religion. (09)
As to "method overriding", I think it is only a curious syntactic
mechanism for two related and valid ideas. (010)
In Smalltalk, the distinction is made between a "message" and a
"method". The idea is that the same semantic request -- the message --
can be made of different individual objects, and different individuals
may have different means of fulfilling that request -- the method. This
idea is just semantically distinguishing WHAT from HOW. In languages
like C++ and Java, the "message" is called the "signature" and the
"method" is the "implementation". (011)
The second idea is just pragmatic: Suppose that a given message is
defined for all widgets, and there are 6 subcategories of widgets, and 5
of the 6 categories implement the message the same way. It is
convenient to define the common method once, and allow 5 of the
categories to say they use it, whilst allowing the sixth category to
define its own proper implementation. The "override" stuff is just the
chosen syntax for doing that. The hidden requirement is that the 6th
category must be disjoint from all of the others, but OO assumes that
all subclasses are disjoint (in order to generate efficient code). (012)
Now the fact that the "override" syntax gives rise to some bizarre
abuses is just the Goedel Corollary for Languages: "You can't allow
everything you want without allowing things you don't want." And
"thinking in Java" is no better than "thinking in Fortran" -- it is one
level of abstraction below that required for the task of software design. (013)
And you are quite right about "island-classes". OO classes are a
programming convenience that has been extended to modeling notions with
a very primitive and unnatural model of classification. To make the
programs efficient, it was necessary to put only that one hammer in the
toolbox. (014)
> Ah, and another one: you'll see what a pleasure it is to have
> MACK resolve the issues that have traditionally landed database
> developers in view-updating problems. That scene is totally
> turned around. (015)
The problem is a little thing called "consistency" and "integrity". I
will indeed be curious to see the solution MACK offers. (016)
Best regards,
-Ed (017)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 FAX: +1 301-975-4694 (018)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (019)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (020)
|