[erlang-questions] Erlang modelling question

Darius Bacon <>
Mon Jun 25 18:07:35 CEST 2007


Damien Morton <> wrote:
> So your problem is one of code management - Darius, who frequents this 
> list sometimes, pointed out that its an instance of the expression 
> problem. see http://www.daimi.au.dk/~madst/tool/papers/expression.txt

That was a different conversation; I haven't really followed this one.

FWIW, if the goal is to code mutable objects with inheritance, the
most straightforward way seems to be with a process for each level of
inheritance for each object: Java code like

class Shape {
  int x, y;
  Shape(int x, int y) { this.x = x; this.y = y }
  void move(int dx, int dy) { x += dx; y += dy; }
  int getX() { return x; }
}

class Square extends Shape {
  int size;
  Square(int x, int y, int size) { Shape(x, y); this.size = size; }
  int getSize() { return size; }
}

might look like

make_shape(X, Y) ->
    spawn(fun () -> shape(X, Y) end).
shape(X, Y) ->
    receive 
        {Self, {move, DX, DY}} -> shape(X + DX, Y + DY);
        {Self, {get_x, Cont}} -> Cont ! {Self, X}, shape(X, Y)
    end.

make_square(X, Y, Size) ->
    Shape = make_shape(X, Y),
    spawn(fun () -> square(Shape, Size) end).
square(Shape, Size) ->
    receive
        {Self, {get_size, Cont}} -> Cont ! Size, square(Shape, Size);
        Other -> Shape ! Other, square(Shape, Size)
    end.

ask(Object, Message) ->
    Object ! {Object, Message}.

(The Self argument is there to allow "superclass methods" to "call
subclass methods", which I forgot to include an example of here.)

This differs from the original post mapping classes to modules.

Darius



More information about the erlang-questions mailing list