Maybe Erlang is OO after all?
Tue Sep 2 13:22:34 CEST 2003
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
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
Hope I've made myself a bit clearer this time :-)
More information about the erlang-questions