Maybe Erlang is OO after all?

[Joachim Durchholz]

Kurt at DBC wrote:
> Joachim Durchholz wrote:
>> With that design, again there's a lot of state involved. If a language 
>> makes it easy to package out-of-band data such as error diagnostics 
>> into results, and where it's likewise easy to disassemble that data on 
>> the caller side, then it's not necessary to have this. 
> 
> Unsure of 'out-of-band',

Say, the sqrt function should return the square root of its argument. Or 
it should return an error indication.
The error indication is what's called "out-of-band data": it's not part 
of the normal "band" that the sqrt function uses to return ordinary results.

In a language with easily defined record types, it's simple to make sqrt 
return either (OK, 2.0) or (Failure, "-4.0 is not a valid argument for 
sqrt").
In a language with pattern matching on records, the caller can likewise 
easily write (made-up syntax)
   case sqrt (x)
   (OK, res) -> <whatever we want to do with res>
   (_, msg) -> <processing for msg>

 > but the (typically implemented) OO method
> of communication via procedure call is what I was driving at:
> the sequence of communicating is explicit (discrete) as opposed to
> Erlangs 'handle any message at any time' approach (continuous).

The approach you're aiming at isn't discrete, it's transactional (since 
messages are discrete anyway): a client "opens" the square root 
facility, stuffs an argument into it, extracts the results, and closes 
the facility so that it becomes free for other clients.

The problem with this approach is that no language really ensures that 
these transactions are atomic. For example, a subclass of the square 
root facility could call itself, inadvertently accessing or even 
modifying internal state that's not consistent with the intended 
interface of the class. (I've seen this happen many times; it becomes a 
real issue once a few dozen classes are involved. Think File classes, 
and a class that uses them to implement virtual file systems within a 
file, plus a specialized File class that accesses these virtual files - 
it's all too easy to get confused without noticing it.)

The problem with this transactional style is that there are many, many 
more ways to have erroneous access to an object (e.g. trying to start 
another transaction while another transaction is in progress). This 
problem would persist even if typical OO languages had full nested 
transaction facilities.

Hope I've made myself a bit clearer this time :-)

Regards,
Jo