I/O from binaries

[Fredrik Linder]

Just want to add som thoughts to this.

Maybe it is a bit "forbidden" to talk about OO here (I don't think it should
be), but is not Chris' proposal a bit like inheritance in OO, the good parts
of it? One super-class defines an interface which many other sub-classes
inherits, so that they all can be accessed in the same way (they all share
an interface :-). Does not activation in mnesia implement something like
this?

Yes, there are both strengths and weaknesess with inheritance. An example of
its strength does Chris' give an sample of in his discussion, and an example
of its weaknesses is huge class-tree structures (that are hard to maintain).

Generally, is Chris' proposal not a good solution?

/Fredrik

> Bengt Kleberg <eleberg@REDACTED> wrote:
>
> > > From: Robert Virding <rv@REDACTED>
> > >
> > > Many have requested a module which allows doing i/o to/from binaries.
> > > Here is a small module I have fixed which does this.  It only
> > > preliminary but seems to work ok.
> > >
> > > The API is:
> > >
> > > bin_io:open_read(Binary) -> {ok,IoStream}
> > > bin_io:open_create() -> {ok,IoStream}
> > > bin_io:open_append(Binary) -> {ok,IoStream}
> >
> > Any reasons to avoid:
> >
> > bin_io:open( Binary, [read] )
> >
> > etc?
>
> I'll go one step further, and ask: is there any reason both the io module
> and the bin_io module shouldn't both adhere to an 'io' behaviour?
>
> I realize that modules that implement behaviours are intended as callback
> modules, but I don't see why they couldn't be used just as well to
> establish an interface for calls of all kinds, not just callbacks.
>
> For example, a function in some other module could take an atom as an
> argument, which would be a module name like io or bin_io (or socket_io,
> serial_io, etc ad infinitum), and use that module for I/O by calling
> Module:open(Object, [read]) and so forth.  This would allow that function
> to seamlessly use whatever I/O its caller specifies.
>
> I think the real benefit here comes from the new behaviour_info/1
> function, so that conformity with an interface can be checked, even at
> compile time.  There are probably other places it could be beneficial, for
> example in the epop package, where a custom database driver can be
> specified; it could be required to live up to an epop_db behaviour, or
> some such.
>
> Any thoughts on this would be very welcome :)
>
> Chris
>