[erlang-questions] Theoretically stuck

[Dominic Williams]

Rudolph van Graan wrote:

> In OO it is trivial to model data and more difficult to 
> customize behaviour.

Having been an OO biggot before discovering Erlang, I would
point out that OO is supposed to be all about modelling
behaviour, NOT data. Hence, trying to mimick OO features to
get data modelling in Erlang might be barking up the wrong
tree altogether

Having said that...

> In FP (erlang) behaviour modeling is trivial and data 
> modeling becomes a challenge.
> 
> How do you write code that wraps the concept/data of a 
> person? A record with name and surname fields is the 
> obvious answer:
> 
> -record(person,{name,surname}).

Records are but one way, the shortcomings of which, given
the current state of records, you have clearly pointed out.

Another approach is to create an abstract data type (ADT): a
module that provides all the functions needed to manipulate
a type. Data gets passed in and out of these functions as
opaque terms which should not be manipulated directly.

The dict module in Erlang is an example of this.

> Now I want to make a version of person with an extra 
> field, say telephone number. Not all records have this.
> Some have a work address as well.

Even in OO, this need not (and probably should not) be
modelled with inheritance. In Java or Erlang, an ADT is
quite capable of managing an optional (possibly undefined)
field, as well as functions that can only be used given
certain preconditions (initial state, including things like
an optional field being defined).

A more legitimate use of inheritance (and even then, many OO
designers prefer delegation to inheritance in many cases) is
to provide an ALTERNATIVE BEHAVIOUR in the event of the SAME
function call.

In OO, this is achieved by subclassing. In FP, this is
achieved using higher-order functions: the common behaviour
is in a function that needs to be passed one or several
functions that perform the specific parts.

Yet another possibility, not FP but Erlang, is to model
objects with processes... The message passing protocol then
becomes the interface, which can easily be extended by any
other module which provides the original protocol.

Regards,

Dominic Williams
http://www.dominicwilliams.net

----