[erlang-questions] Misultin EOL

[Tim Watson]

On 17 February 2012 23:31, Yurii Rashkovskii <yrashk@REDACTED> wrote:

> Andrew,
>
> >I think a lot of issues with APIs would be solved if we had something
> analogous to Java interfaces in Erlang.  Behaviors just don't cut it.  I
> want something that is a replica of interfaces.  Then all the Erlang guys
> have to do is create the interface and then people can create whatever
> implementations they want and I never have to worry about changing my code!
>
> I think this new -callback stuff is more apt to solving the problem of
> interfaces.
>
>
If I've understood this properly, then the -callback thing will provide a
compile time check for the implementors of the callback interface into the
custom behaviour, but gives nothing to the (external) client. Now what
Andrew and I are looking for in practise, is something roughly like

DbHandle = dbms:bind(pgsql, DriverConfig),
DbConnection = dbms:connect(DbHandle, dbms:connection_info(Catalog, Schema,
AuthMode))
Results = dbms:execute_query(DbConnection, "select * from foo"),
dbms_result_set:foldl(Results, [], fun collect_foobar/2)

So I can change 'pgsql' to 'pgsql2' or 'oracle-oci' or 'mysql' or whatever,
I can call connect/2 with *any* valid `-opaque db_handle() :: ...' data,
call execute_query/2 with *any* valid `-opaque db_connection() :: ...' and
I can rely on all implementations returning a structure that I can pass to
dbms_result_set foreach/map/foldl and it will 'just work' even if the
result set has to have a 'pointer' to those functions or (less tidily) I
have to pass the DbHandle to those functions.

Here I can clearly rely on only the 'dbms' API and the people who have to
do the heavy lifting are the implementors or 'pgsql' and similar libraries,
who have to make sure that their libraries conform to the -callback
interface(s) defined by the dbms application. I think though, that there is
a question of state that makes this a bit awkward in practise (because even
if there are no processes behind the custom behaviour, you still have to
maintain the binding to the implementation module(s) somewhere) and also it
makes implementing the API more complicated than simply saying 'define
these callback functions'. I think this is why so many API efforts (such as
simple_bridge) seem to end up using parameterised modules.

A classic example of this is the recent conversation about unifying the
dict APIs, but you could apply that to lots of other situations. How can I
do that using the -callback approach?

D = dict_api:new(dict | orddict | ....)
%% add some stuff
dict_api:find(key1, D2)

So at a minimum, the implementor of dict_api needs to return (a) the module
that implements its -callback interface and (b) whatever state/data that is
required in order to fulfil any subsequent call. Now if there was a bit of
sugar that allowed me to do this dbms:bind and dict_api:new stuff so that I
only need to

1. define the -callback interface somewhere as the API
2. have a way to get an implementation of the callback interface for any
module that provides that -behaviour

then things would be good right!? But I want this to work without breaking
hot loading/upgrades, so I'm not convinced that it's so easy to do when
you're effectively spending a lot of time passing around the module name(s)
in a bunch of variables or embedded in some records or whatever. What we're
looking for is a way to say

%% bind the -callback source to an implementation
-bind(api_module, implementation_module).

do_something() ->
    api_module:do_something(....)

And make sure that when an upgrade takes place, that what's *really*
happening is that the call is being made to 'implementation_module' and any
change to 'implementation_module' will trigger a proper code change. I
suppose this might be achievable with a parse_transform (that translates
from mod_api to the other) but that feels a bit messy and it would be nice
for the compiler to check the client code for consistency with the exported
-callback API too.

That's probably a terrible approach, but I hope you get the gist of what
we're thinking about.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120218/fa2cfc54/attachment.htm>