Mon Jul 28 11:28:59 CEST 2003
--- Per Bergqvist <per@REDACTED> wrote:
> Still don't see why one would like to use a
> -behaviour if there
> is no underlying support for it. It will basically
> be a no-op except
> for the warning. Am I missing something ?
As far as I know, all behaviours work that way: they
just verify that the module exports the right
I think, however, that user-defined behaviours are an
excellent idea: behaviours are useful because they
formalize an expected interface and provide the basis
for further documentation. A bit like Javas
(With user-defined behaviours, one also has the gotcha
that the behaviour files should be compiled before any
of those who use the behaviour.)
If a module has several behaviours, which I *do* think
should be possible, a linter should probably check
that their required functions do not overlap. In that
case, something is likely to be wrong.
Okay, that's the main reply. I have been thinking a
bit about behaviours, so here are some more things to
* Should we keep around the fact that a module has a
behaviour, so that we can check this at runtime?
(e.g., gen_server can check that the callback module
has -behaviour(gen_server)). module_info/1 can keep
track of this easily.
(Strictly speaking, this is *not* the same thing as
the module exporting the functions required by
* Should behaviours also *require* some functions (ie,
yield an error rather than a warning if f/n is not
* Should we have versioning of behaviours, beyond the
versioning of SASL? (Several versions of foo_b in the
* Finally, I would like a mechanism for composing
behaviours: roughly speaking, that
B = compose(B1,B2,B3)
yields at runtime a "module" B that behaves like
modules B1 and B2 and B3. (Usable for any number of
There is a straightforward way of doing this --
dynamically generate and compile a new module -- but I
think that's a bit too heavyweight and might not quite
do the right thing.
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
More information about the erlang-questions