Ker,OOOOOOOOO far21

[Michael David WINIKOFF]

> 
>  In older manuals, objects were define as an embedding of code and data.
> Now, I will rather say that code and data are different aspects of objects.
>  Objects are a unifying scheme in computer science. Some call it schemes,
> others call it functions, some may call it God, etc. The fact is we can
> seek unity in computer programming (code and data or yin and yang aspects
> of the Tao; one feeds from the other).
>  This unity was broken when (micro)processors were built so complicated,
> that code to handle data was as foreign to data as data to represent code
> was from machine code.
>  But unity was rediscovered, and may be achieved again.

This is exactly the metaphysical crap we don't need -- objects should NOT
be a religion.

> 
>  Object are everything; everything is an object. Unix tried to say that files
> are everything, that everything could be done with a file; but Unix files
> were thus implemented that only big objects could be efficiently represented
> that way; and Unix didn't provide any code embedding with this data; and Unix
> forced people to access data through strings. So that the system wasn't a
> unified system.
> 
>  There came MOOSE, which raised hope among young programmers. It at last
> was a unified system. But it wasn't a closed unenhanceable, unextensible
> system. It provided generic polymorphic object managing: objects were
> implemented through descriptors who themselves were objects. Objects had
> a recursive definition, so that the only basic code/data was a convention
> on how to code objects so that others are aware of it and its methods.
> 
>  Objects had basic methods:
> - get object's descriptor : (if you have the object's descriptor, you have it)
> - copy the object
> - send a message to the object. For example a dictionary entry to add to the
> object's dictionary.
> 
>  Objects descriptors came in tiny, small, medium. large, huge groups named
> dictionaries.
> (to be continued ...)
>  
> 
> 
> 

As far I'm concerned (IMHO, feel free to arguye/flame) objects are usually
very wishy washily defined.

The main reason (IMHO) is that the concept of OO contains a number of separate
distinct concepts that have been lumped together.

(1) Data abstraction -- accessing data only through the interface
(2) Inheritance -- this is a code reuse issue
(3) POlymorphism and overloading -- these are typing issues

This is usually associated with a layer above an imperative langauge. 
However ...
(1) Polymorphism can be done (and has been) in declereative languages
(2) Haskell's type classes implement overloading (and a form of inheritance)
(3) Data abst5action is not at all related to imperative languages.

 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.