extending standard behaviours

Vlad Dumitrescu vlad_dumitrescu@REDACTED
Thu Apr 18 08:45:33 CEST 2002


Hi Chris,

I have been thinking along those lines too, but never got to try it in 
practice. :-)

First a note: for some reason Hotmail thought rusty.erl contains a virus, 
and refused to download it... Hmmm ;-)

>The problem is that gen_loud_cat must cache it's callback module in an ets
>table - because I couldn't see any other way for it to 'remember' what
>module is implementing it.  That's not very elegant at all.

The alternative would be to extend the State of the gen_cat server, and 
store the callback there. Anyway, there must be a way to ask gen_cat for its 
state.

>I guess object-oriented languages use a list of superclasses - I know Perl 
>does
>something like that - but if Erlang behaviours are written with only a
>singleton callback module in mind - it might be difficult to extend them.
>It might be easier, if they were written with a list of callback modules
>in mind.

Right! OO languages do their magic by means of extensive support from the 
compiler and the runtime. It can be accomplished "the hard way" (tm), but it 
won't be nice nor easy. Think what it would be like to implement C++ classes 
in C... scary!

The same extensive support from compiler/runtime we get in Erlang for 
pattern matching and receive statements (see ongoing discussion about that). 
This way we get expressiveness and clarity -- OO languages use just another 
approach.

>Or perhaps I simply missed something.  The other odd thing that I didn't
>initially expect (thinking about this in somewhat too-OO terms) is that
>whether, for example, puff.erl behaves to gen_cat or gen_loud_cat is, on
>one level, irrelevant, since they both expose the same interface.  The
>only difference is in how it's implemented- the specific behaviour.  You
>can change the single line -behaviour(gen_cat) to -behaviour(gen_loud_cat)
>in puff.erl, and this changes puff's behaviour.  But this is a good thing!

Why didn't you expect it? It's the same in OO - if you define a class with a 
public method, and inherit from it without changing the interface, then it 
isn't really relevant to which class an object belongs, it's only a 
difference of behaviour. Polymorphism! ;-)

regards,
Vlad

_________________________________________________________________
MSN Foto är det enklaste sättet att dela eller skaffa papperskopior av dina 
foton: http://photos.msn.com/support/worldwide.aspx




More information about the erlang-questions mailing list