Chandrashekhar Mullaparthi Chandrashekhar.Mullaparthi@REDACTED
Mon Jul 28 13:34:35 CEST 2003

> -----Original Message-----
> From: Thomas Lindgren [mailto:thomasl_erlang@REDACTED]
> --- 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 ?

> * 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
> gen_server :-)
> * Should behaviours also *require* some functions (ie,
> yield an error rather than a warning if f/n is not
> exported)?

I dont think requiring some functions is a good idea. gen_server for
instance provides three different ways for a server to interact with the
outside world. If I choose to use only gen_server:call in my server, I dont
want to provide dummy functions and clutter the code. The same could be said
of user defined behaviours.

Taking the example of Java interfaces, the Java compiler enforces
implementation of all functions in an interface which leads to lot of
bloatware when writing new classes.


This email (including attachments) is confidential.  If you have received
this email in error please notify the sender immediately and delete this
email from your system without copying or disseminating it or placing any
reliance upon its contents.  We cannot accept liability for any breaches of
confidence arising through use of email.  Any opinions expressed in this
email (including attachments) are those of the author and do not necessarily
reflect our opinions.  We will not accept responsibility for any commitments
made by our employees outside the scope of our business.  We do not warrant
the accuracy or completeness of such information.

More information about the erlang-questions mailing list