Structs (was RE: Record selectors)

[Peter-Henry Mander]

No, your not a freak, at least not in my opinion :-)

I find the problem with OO is that the definitions can be dogmatic when 
dealing with a programming problem. Newcomers tend to feel that if they 
don't use *all* the OO concepts to solve a problem, then they're doing 
something wrong.

What I like about the Erlang approach is that I can overlay OO if I 
want, but I don't have to. Also the use of modules and *real* message 
passing actually leads to a far more powerful concept of concurrent 
objects (not OO "message" function calls within the caller context, 
something that bothered me initially, a long time ago). I haven't found 
a more convincing implementation of this elsewhere.

Pete.


Chris Pressey wrote:
> On Mon, 27 Jan 2003 13:43:41 +0100 (MET)
> Bengt Kleberg <eleberg@REDACTED> wrote:
> 
> 
>>
>>>On Wed, 15 Jan 2003 09:18:38 +0100
>>>"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu@REDACTED> wrote:
>>>
>>
>>...deleted
>>
>>>From the OO literature I've read, three tenets seems to be universally
>>>agreed upon: encapsulation, polymorphism, and inheritance.  Two others
>>>get mentioned often enough, abstraction and identity, but they seem
>>>less well understood.
>>
>>sorry about this late email, but i had to get my copy of ''object
>>oriented software construction'', by bertrand meyer, back before i
>>wrote anything.
> 
> 
> Sorry, I've been a bit busy too.
> 
> 
>>in chapter 2, ''criteria of object orientation'' there are 15 pages
>>devoted to what object orientation (o-o) is. there are 3 cathegories
>>1 method and language (20 criteria)
>>2 implementation and environment (5 criteria)
>>3 libraries (4 criteria)
>>also mentioned is the fact that o-o is not a boolean concept.
>>''environment a, although not 100% o-o, may be more o-o than
>>environment b''.
> 
> 
> I think that terms like OO (or OTP) sometimes take on far too
> wide-reaching a meaning, and become impractical for debate  :)
> Having 29 criteria makes a pretty hefty definition.
> 
> To me, OO just means code and data (state) are grouped in units.  All the
> other tenets I've seen seem to follow from that principle.  Erlang modules
> currently work fairly well for the purpose, and with enough effort I'm
> sure any OO technique could be implemented on top of them; but more
> usually, I'll bet Erlang programmers just code up discrete abstractions to
> serve the specific purposes they have in mind right then.
> 
> In other words, I find it's really not that different programming in
> Erlang than programming in your typical OO language, but you build what
> you need and only what you need of the OO framework when you need it. 
> Modules I write tend to look a lot like:
> 
>   -module(rectangle).
> 
>   -record(rectangle, {width, length}).
> 
>   new(Config) -> config(#rectangle{}, Config).
> 
>   config(Rectangle, []) ->
>     Rectangle;
>   config(Rectangle, [H | T]) ->
>     config(config(Rectangle, H), T);
>   config(Rectangle, {width, N}) when number(N) ->
>     Rectangle#rectangle{ width = N };
>   config(Rectangle, {length, N}) when number(N) ->
>     Rectangle#rectangle{ length = N }.
> 
>   width(Rectangle) ->
>     Rectangle#rectangle.width.
>   length(Rectangle) ->
>     Rectangle#rectangle.length.
> 
>   perimeter(Rectangle) ->
>     2 * (Rectangle#rectangle.width + Rectangle#rectangle.length).
> 
>   etc.
> 
> Of course it varies greatly.  When it's a server instead of an inert lump
> of data, new/1 might be called start/1, and it might spawn a process, with
> which the other functions might communicate with message sending or
> gen_server calls.  It might also create ets tables.  Setting properties
> might have width/2 and length/2 functions, or a read/2 function, for
> convenience.  The functions might return {ok, Rectangle} or {error,
> Rectangle} instead of just a new Rectangle.  Etc.  But it's basically the
> same.
> 
> If an external module needs the underlying representation for whatever
> reason, it can be exported by a function called record_info/1 which wraps
> around the record_info macro.
> 
> The association between the names serves to make the grouping adhere: if
> the module is named rectangle, the instance variables are named
> Rectangle or RectangleSomething, the ets tables and other global names
> should be named rectangle too (and the ?MODULE macro makes this easy.)
> 
> Am I a freak, or do other people find that it helps to write modules this
> way - basically, to hide each data structure behind interface code?
> Would structs obsolete this discipline, and if not, how could they be
> enriched to do so?
> 
> -Chris
> 
>