Subject: RE: behaviours - msg#00217

Previous Message by Date: click to view message preview

RE: behaviours

--- Fredrik Linder <fredrik.linder@xxxxxxxxxxxxx> wrote: > Good point. Versioning is definitely desired, > perhaps something like: > > behaviour_info(callbacks) -> [{Function, Arity}]; > behaviour_info(version) -> Version; > behaviour_info(_) -> undefined. It would be nice to integrate behaviour versions with applications and releases too. I'm not sure what's right, though. It might be straightforward. (Simply take the vsn attribute?) A complicating case: several versions active in the system at the same time (due to use of legacy code, say). Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

Next Message by Date: click to view message preview

RE: behaviours

--- Richard Carlsson <richardc@xxxxxxxxx> wrote: > To be picky, I'd like to remark that we're talking > about the > behaviour/interface of _modules_, not _processes_, /.../ Yes. > We just don't have a good, general way of specifying > real behaviour in a > sufficiently abstract and formal way, except for the > code itself. So > meanwhile, we just specify the interfaces and cross > our hearts. It's not always clear what we want to specify either. (And finally, my vote goes to keeping "-behaviour".) Best, Thomas __________________________________ Do you Yahoo!? The New Yahoo! Search - Faster. Easier. Bingo. http://search.yahoo.com

Previous Message by Thread: click to view message preview

RE: behaviours

> From: Wiger Ulf [mailto:ulf.wiger@xxxxxxxxx] > > As far as I can tell, this discussion is analogous to the single- vs > multiple inheritance debate in OO. True > The main thing that is missing in order to support use of multiple > behaviours in one module is some remapping facility. One could > imagine using funs for this in a way that could be transparent and > add minimal overhead. Example: > > -module(ex). > -behaviour(a). % expects init/1 and foo/0 > -behaviour(b). % expects init/1, foo/0 and bar/0 > > -export([a_init/1, a_foo/0]). > -export([b_init/1, b_foo/0, b_bar/0]). > > -export([behaviour_redirect/1]). > > behaviour_redirect(a) -> > [{init, 1, fun a_init/1}, > {foo, 0, fun a_foo/0}]; > behaviour_redirect(b) -> > [{init, 1, fun b_init/1}, > {foo, 0, fun b_foo/0}, > {bar, 0, fun b_bar/0}]. > > %% Now we can separate overlapping callbacks and group > %% the functions in the most intuitive fashion. > a_init(Arg) -> ... > a_foo() -> ... > > b_init(Arg) -> ... > b_foo() -> ... > b_bar() -> ... > > The behaviour would have to understand to use > function_exported(M,behaviour_redirect,1) and use default callbacks > for functions that are not explicitly redirected. This operation would > be called when the module is "instantiated". It would entail some overhead > for behaviours that are not really instantiated (such as mnesia > callbacks), > but behaviour redirection would not have to be mandatory. Yes, either something like this or promptly deny overlapping behaviours. Maybe even ban using the same function name. Doesn't the given example require that the caller of each of these functions also state on behalf of which behaviour it calls them hence making it overly complex? Something like: init(Settings) -> A = M:init(Settings) using behaviour(a), B = M:init(Settings) using behaviour(b), init_state(Settings, A, B). /Fredrik

Next Message by Thread: click to view message preview

RE: behaviours

> -----Original Message----- > From: Thomas Lindgren [mailto:thomasl_erlang@xxxxxxxxx] > > --- Per Bergqvist <per@xxxxxxxx> 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. regards Chandru NOTICE AND DISCLAIMER: 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.