Re: Object equals Relation

A long time ago, in a galaxy far, far away, topmind_at_technologist.com (Topmind) wrote:
>>
>> Have you read the third manifesto? A must-read on this subject, but
>> hardly the last word -- the authors are too lacking in practical
>> knowledge of OO languages to finish the matter. (Several cases of "OO
>> cannot do this" claims which are easily rebutted with "can do and do
>> quite easily with a good OO language".).
>
> I don't really question the idea that relational and OO can be merged
> (somehow). It is not a matter of what OO and relational *can* do, but
> is about providing specific and consistent roles.

I think it's a matter of establishing a _clear_ theory as to what's what.

The relational algebra provides that for relational systems; there is no such clear "object calculus" on the OO side of the fence.

It's not that no "object calculi" exist; it's that there are so many of them, with substantially different models.

There's the "message passing" approach of Smalltalk. The "class" approach of Simula. The "multiple dispatch" of CLOS. Every language implements a slightly different model of what objects are, and how they interact. That doesn't mean that there are 150 completely different ways of thinking of OO, for the huge number of "OO languages," but it most certainly _does_ mean that there are multiple ways of thinking about OO that are in active use.

Nobody is going to come out tomorrow with _The One True OO Calculus_ and be able to expect it to be adopted en masse, because that would require trash-binning all the code written with the existing Hordes of OO Models.

The fact that the author of Xdb (which, by the way, conflicts with the name of XDB, an SQL database system that emulates DB/2... I'm surprised he hasn't been sued by the trademark holders...) can express wishful thinking that everyone else should think of OO in the way he does does not establish that anyone will actually do so.

> GOF patterns are similar to "conventions" that one may use to
> organize Goto's. I tended to develop certain Goto patterns to keep
> my sanity back then. I am surprised books didn't come out with names
> like "Patterns of Flow Control with Goto's", by the Gang of Five.

The Gang of Five came about because they did seminars and sold software and such all about their "methodologies."

If pundits had gotten together to do seminars about "Flow control patterns for GOTOs," I'm sure it could easily have happened.

> Nobody has been able to describe the "benefits" of nested blocks
> with rigorous mathematical precision after all these years. It
> generally appears to be about psychology. Inter-developer
> consistency is the best way I have found to describe the benefits.

The mathematical rigor that exists in the relational calculus doesn't exist for control structures nor does it exist for OO. You can't _prove_ that a particular OO model is "correct," only that it might be consistent with what the proponent wants to say.

> Patterns are often a symptom, not a solution, just like the Goto
> days. They are an (futile) attempt to reign in run-away complexity.

The APL perspective (to draw in a very different community) would be to term them to be "idioms."

In APL, there are all sorts of combinations of operators that come up again and again, and get called "idioms."

I think the "pattern" movement is all about recognizing and not-quite-formalizing sets of useful "idioms."

In human language, "idioms" are the bits of phrasing that represent somewhat arbitrary "namings" of things. They are convenient for getting ideas across quickly, _when everyone listening understands the idiom_.

Idioms aren't "proven to be right;" they are agreed upon as useful for communication.

And I think that's _exactly_ what happens with "Patterns." They're not mathematically provable; they are just idioms that people agree on as useful.

> The organizational techniques beyond (above) the class granularity
> is hardly more well documented and agreed upon than Goto patterns.

Different OO implementations do not document or agree upon the same semantics for classes, methods, and such, and have different sets of idioms. Smalltalk is not the same as C++ is not the same as Perl is not the same as CLOS (which is an object system subsuming a whole bunch of object models).

-- 
(concatenate 'string "cbbrowne" "_at_cbbrowne.com")
http://www.ntlug.org/~cbbrowne/sgml.html
"Your job  is being a professor  and researcher: That's one  hell of a
good  excuse  for some  of  the  brain-damages  of minix."   
-- Linus Torvalds to Andrew Tanenbaum