From: Dmitry A. Kazakov on
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
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
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
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
> 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.