guidance

[Thomas Lindgren]

--- Matthias Lang <matthias@REDACTED> wrote:

> Am I completely misunderstanding something? Surely
> you're
> not arguing that OO doesn't allow side effects?! 
> 
> If I rewrite your last sentence. "In a class, the
> response [can]
> depend[s] on which state you are in", that doesn't
> seem unnatural
> in many popular OO languages. 

That's right, both processes and objects are stateful.
The difference is I am thinking of is what code is
executed when a method is invoked (or a message is
sent). Note also that this is a question of
convenience rather than expressive power. (Both are
Turing complete, right?)

Let me take a silly example to illustrate: consider an
object with two states (as in a state machine), open
and closed. The methods/messages vary in
implementation with the state and there are perhaps
many methods. We implement this object as a process.

In naive Erlang, using a single receive (corresponding
to a single set of methods in a class):

process(St) ->
   receive
     {From, is_open} ->
        case is_open(St) of
           true -> From ! true;
           false -> From ! false
        end, process(St);
     {From, flip_state} ->
        case get_state(St) of
           open -> process(set_state(closed, St));
           closed -> process(set_state(open, St));
        end;
     ... lots more methods ...
    end.

That is, you need to look in your explicit state and
modify it as you get messages/method calls. The state
is encoded in the instance variables. If you have a
lot of state variables, you may need to update a lot
of them when the state changes. Adding new states can
become tedious and error-prone, etc.

In naive Erlang with one state per receive:

open(St) ->
   receive
     {From, is_open} -> From ! true, open(St);
     {From, flip_state} -> closed(St);
     ... etc ...
   end.

closed(St) ->
   receive
      {From, is_open} -> From ! false, closed(St);
      {From, flip_state} -> open(St);
      ... lots of other methods ...
   end.

Adding a new state now means (a) a new state function,
and (b) transitions to/from the new state. In
Erlang/OTP, the difference between gen_server and
gen_fsm, if you will.

A similar construct for OO, "predicate classes", was
proposed by Craig Chambers in 1993. (That paper was
what made me think along these lines.)

<http://www.cs.washington.edu/research/projects/cecil/www/pubs/predicate-classes.html>

Anyway, I hope I have illustrated how standard OO
method calls (without inheritance) differs from
message passing to Erlang processes.

Best,
Thomas



	
		
__________________________________
Do you Yahoo!?
Win a $20,000 Career Makeover at Yahoo! HotJobs  
http://hotjobs.sweepstakes.yahoo.com/careermakeover