I/O from binaries

Chris Pressey cpressey@REDACTED
Tue Nov 6 00:50:02 CET 2001

On Mon, 5 Nov 2001 08:17:24 +0100 (MET)
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 :)


More information about the erlang-questions mailing list