behaviour vs. data first
in [OOP]
|
Prev: Informatics 2010: 1st call extension - 30 April 2010
Next: The Eiffel Compiler tecomp version 0.22 released
From: Dmitry A. Kazakov on 11 Apr 2010 02:03 On 10 Apr 2010 23:10:20 GMT, Stefan Ram wrote: > raould <raould(a)gmail.com> writes: >>dunno if you read the paper, but my interpretation was that they are >>not defining the types, they are defining the actual internals of the >>records, which is a different thing. you can define apis with types, >>without knowing what the internal details of those types are. > > A /client/ of an abstract object is supposed to just know > the interface of that abstract object - not the > implementation of that abstract object. (And the author of > the clients is supposed to know the documentation of this > interface, but not the source code of its implementation.) Objects (in a program) are instances they are never abstract, always concrete. > Alan Kay coined the term �object-oriented programming�, and > when asked about it, he said: > > �I wanted to get rid of data.� The importance of this was discussed here in comp.object on numerous occasions. There is no data, only behavior. > In mathematics, abstract objects (possibly with state) can > be described using Coalgebras, IIRC, see, for example There are different ways to describe computational systems. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: raould on 12 Apr 2010 14:07 On Apr 10, 11:03 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > The importance of this was discussed here in comp.object on numerous > occasions. There is no data, only behavior. i'm searching the archives, but haven't hit anything yet - might you have any direct urls? i can see OO as being data+behaviour if you look at it from the implementation side; OO is about encapsulation. on the other hand there are ways to implement OO where even the "data" is implemented only via procedures; that's the "hard-line" approach to OO as i understand it. this is different than the C++/C#/Java/etc. approach which sorta mixes in 'regular' old data. tho i think part of the problem here will be that we have to define "data" and "behaviour"; it is likely that people will interpret those words in different ways, sufficient to cause sturm und drang. sincerely.
From: Dmitry A. Kazakov on 12 Apr 2010 15:20 On Mon, 12 Apr 2010 11:07:25 -0700 (PDT), raould wrote: > on the other hand there are ways to implement OO where even the "data" > is implemented only via procedures; that's the "hard-line" approach to > OO as i understand it. Data as a structure is an interface with some implied implementation. ADT assumes that interfaces are always separated from the implementations. This breaks data into two pieces. There is no data anymore, it is *abstracted* away, as the name suggest. > this is different than the C++/C#/Java/etc. > approach which sorta mixes in 'regular' old data. Yes, these language have design problems. > tho i think part of the problem here will be that we have to define > "data" and "behaviour"; it is likely that people will interpret those > words in different ways, sufficient to cause sturm und drang. I think there is a consensus on the meanings of data (there are many, but the contexts they are used do not overlap) and behavior. The key disagreement between data-driven folk and OO is that the former believe that the behavior is somehow derivable from the data, this in particular is typical for DB-people. From a mathematical point of view it is a fruitless approach, just because reasoning from data is necessarily limited by the computational power etc. OO tells, OK we won't even try, it is irrelevant what is inside, so long the behavior is fine. Integer is something you can sum, subtract, multiply, divide etc. If you can do this you have an integer. The behavior exhaustively defines the thing. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: raould on 12 Apr 2010 16:56 On Apr 12, 12:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > From a mathematical point of view it is a fruitless approach, just because > reasoning from data is necessarily limited by the computational power etc.. > OO tells, OK we won't even try, it is irrelevant what is inside, so long > the behavior is fine. Integer is something you can sum, subtract, multiply, > divide etc. If you can do this you have an integer. The behavior > exhaustively defines the thing. thanks, i think i can grasp that point. sincerely.
From: raould on 13 Apr 2010 13:38
> On Apr 12, 12:20 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: > > > From a mathematical point of view it is a fruitless approach, just because > > reasoning from data is necessarily limited by the computational power etc. > > OO tells, OK we won't even try, it is irrelevant what is inside, so long > > the behavior is fine. Integer is something you can sum, subtract, multiply, > > divide etc. If you can do this you have an integer. The behavior > > exhaustively defines the thing. tho, there is more to it since you can sum, subtract, multiply, divide etc. not just integers. sincerely. |