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