Newsgroups: comp.object,comp.databases.object,comp.lang.java,comp.lang.smalltalk,comp.lang.c++,comp.lang.eiffel,comp.lang.objective-c,comp.software-eng
Path: cantaloupe.srv.cs.cmu.edu!bb3.andrew.cmu.edu!newsfeed.pitt.edu!gatech!newsfeed.internetmci.com!in2.uu.net!EU.net!sun4nl!Utrecht.NL.net!hacom.nl!gamp.hacom.nl!news
From: albert@gamp.hacom.nl
Subject: Re: Data-driven vs. Behavior-driven OO Methods: a Non-Issue?
X-Newsreader: Gnus v5.0.10
Sender: albert@beowulf.gamp.hacom.nl
Lines: 57
Organization: We aren't! Should we, then it's SW, Education and Advice.
Message-ID: <86n37i3ie4.fsf@beowulf.gamp.hacom.nl>
References: <4dhop7$3aj@suez.iconcomp.com>
In-Reply-To: dsouza@suez.iconcomp.com's message of 16 Jan 1996 21:00:55 -0600
Date: Sat, 20 Jan 1996 17:06:43 GMT
Xref: glinda.oz.cs.cmu.edu comp.object:43921 comp.databases.object:8857 comp.lang.java:17814 comp.lang.smalltalk:33740 comp.lang.c++:169960 comp.lang.eiffel:12592 comp.lang.objective-c:4766 comp.software-eng:41325


Desmond F. D'Souza writes in  <4dhop7$3aj@suez.iconcomp.com>

> There has been much controversy and discussion about methodologies
> that are behavior-driven vs. those that are data-driven, with
> OO-"purists" arguing vehemently against data-driven approaches. In
> this paper, we suggest that the difference may be smaller than often
> thought, if we adopt a simple definition of a "type model".
 
> Paper available:
> <A HREF="http://www.iconcomp.com"> On the Web</A>

I have got the paper, (first one in a series of 1)

It start great:  (free abstracts)

"There are two aproaches ... but ussing the `type model` there are
simulair".

And: "Using the (new, our) Catalysis solves al problems."

After the introduction and some examples, that line is gone !

I'm sorry to say so, but it IS a nice story about nothing. Some new
words and myths are introduced, which are solved by renaming them.

One example is about a "Stack", which IS a relevant one. 

That examples says: do not just say a stack is " ....", be specific. 

I thing we ALL know that. It is like old good programming: 
                printf() should behave as printf!  
But there is hardly a need to specify that. So is a stack. it should
behave like a stack! So all counter-examples of the paper that decribe
a FIFO, ar a list or ... are no stacks!

It's so simple: a strack is only a stack if it behaves like one.

But it is also true, some more complex "objects" shoul be described
better. But do not make the mistake to solve this by specifing it by
other "informal words" That just hides the problem, it doen't solve
it.

So, back to printf(),: it ain't very helpfull to say:
       "C's  printf() is simmular as pascals writeln(), but with ..."
 Aside from being false, it also not clearifying the problem. Not in
any formal/secure manier.
 Of course it helps to "talk it over" or tho learn a pascal-programmer
to write C. but that is it.

Second, after some kind of intro about type-model, there is no
coupling between that type-model (or Catalysis) and the original
-- intressting-- problem: the differance/simularity between data-driven
and behaviour-driven.

---GAM
"This should be a jolly quote"
