Maybe Erlang is OO after all?

[Kurt at DBC]

Joe Armstrong wrote:
> I have been reliably informed that maybe Erlang *is* OO after all.
> 
>   Isolation  is needed  to implement  true  objects -  they *must*  be
> isolated processes are  a very good approximation to  true objects (in
> as much as two Erlang processes are fairly well isolated)
[...]
> 	- Erlang *is* OO
> 	and
> 	- Erlang is *more* OO than any of the other so called OO languages
[...]
>   Put that in your pipe and smoke it!
>   Cheers

It seems to me that there is a big difference between processes and
objects in that objects, or OO, don't take account of time.
So Objects are discrete, whereas Processes are continuous.

If you don't ever take time into account the isolation of private 
methods/members work very well -  the object discretely changes
from one state to the next and it doesn't exist between states.

Which is why the old example of :
/* start */
create Object {
   var x = 0;
}

Object.function(y){
   set x = y;
}

output of Object {
   set result = 100/x;
   //but what is the value of x here?
}
/* end */

is seen as right by OO people:
  -Object doesn't exist
   -> step 1 : object created
   -> step 2 : object exists in state x=0
   -> step 3 : object set to state x=y
   -> step 4 : output object

and wrong by non-OO people
  -Object doesn't exist
   -> step 1 : object created
   -> step 2 : object exists in state x=0
   -> step 3 : object exists in state x=y

who fear one of the paths :
    in parallel:
   -> step 3 : output Object {Bang! Error : divide by 0}

    or sequentially:
   -> step 4 : object set by "someone else" to state x=0
   -> step 5 : output Object {Bang! Error : divide by 0}


This, ISTM, is also why in OO (admittedly Object Pascal, Java and
guessing at C++) threads are so difficult to manage, as they are 
implicitly time-based, so the thread object can only _simulate_ being in
a distinct state (either by polling or blocking) when it is actually in 
a different state during any time interval - and in no particular state 
at a given point in time.

Processes, by handling the time component of state can basically
emulate an object, as they can quite naturally enforce the isolation,
polymorphism and the inheritance, which is why :

> claiming OO for Erlang is a bit like claiming
> functionalness for C - yes you *can* do it, but it's not practical

although rather than "practical" I'd say "native".

Alternatively, I'd suggest that items in a database would be more
easily represented by an OO language as the states are very explicit
and very distinct - due to having an enforced commit or rollback,
the database items also don't exist between states.

Anyway : dutifully smoked. (Or dutifully me.pipe.smoke.earlier()  ;)

Cheers, Kurt.

ps: Never noticed before how OO has stolen a whole lot of usefully
descriptive words.
Try describing the time component without using the word  "component",
or database `items` without using the word "object".