Ed, (01)
Thanks for the understanding (and the minor correction). (02)
> I have learned to use OO terminology in order to communicate with
> most of the software engineering community for the last 20 years. (03)
Me too, and I've often insisted on the web that, properly viewed, it's
merely "plain logic". (For example, just google '"plain logic"
metaset'.) (04)
> But I adhere to a different modeling religion. (05)
That being? (06)
> As to "method overriding", I think it is only a curious syntactic
> mechanism for two related and valid ideas.
>
> 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".
>
> 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).
>
> 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. (07)
While I can quite understand the short-term convenience of it, my
problem with method overriding is that it torpedoes the Liskov
Substitution Principle: an instance of a subclass is no longer
guaranteed to be an instance of the baseclass. That's more than just
a bizarre abuse -- it's an overthrow of polymorphism as well as
inheritance. (08)
>> 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.
>
> The problem is a little thing called "consistency" and "integrity". (09)
Indeed. And you'll see how both those qualities really are the basis
of everything in a MACK-compliant world. (010)
> I will indeed be curious to see the solution MACK offers. (011)
Oh, it's more than just a solution to a little problem, it's a way of
thinking and working, across the board. Luckily you won't have to
await any magnum opus -- it features rather centrally in the upcoming
instalment. Basically, after all, it is even terribly simple and
obvious. (012)
I shall look forward to your critical examination of it, and of my
exposition of it. (013)
Christopher (014)
_________________________________________________________________
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 (015)
|