Re: [Caml-list] Re: Common IO structure

[Gerd Stolpmann <info@gerd-stolpmann.de>]

On Mon, 2004-04-26 at 21:28, Nicolas Cannasse wrote:
> > And from my point of view, your proposal has some problems.  For one
> > thing, it is not compatible to the already existing I/O channels in
> > other libraries than Extlib.  Camomile uses get and put for your read
> > and write, and ocamlnet and cryptokit uses input and output (IIRC) for
> > your nread and nwrite.
> 
> So ? That's exactly what we're talking about it there : making a choice. And
> that include naming of course. I don't say that the name we choosed for
> ExtLib IO are better, it's just that "reading" and "writing" on an IO seems
> natural to me.

That sounds like a paraphrase for "better" without using this word. I
would like to hear real arguments for why certain names should be used.
For example, one reason can be that there is already a user base.

I think names are just names, and there are usually several ways of
referring to things. However, when several independent libraries
_choose_ to name their methods in a coherent way, I would say this is
very intelligent.

> > Another problem is that it is not minimal
> > enough.  For character converters, it is impossible to predict how
> > many characters will be available, for example.  And requiring "pos",
> > "nread", "nwrite" seems arbitrary for me.  They are somtimes useful
> > and improvement, but not necessary.
> 
> That's true, I agree with you but on the last point : they are necessary in
> order to get good performances. Concerning "available", it returns None if
> no data available. "pos" might throw an exception as well when unavailable
> (looks like pos and available should have same behavior here). And
> nread/nwrite can simply call n times read/write. That means that any library
> can put default implementation for additional "not minimal" constructs :
> they will behave poorly (writing a string char by char) but will interface
> well with other IO that are supporting them correctly. If implementing
> efficently nread/nwrite require additionnal effort, then let's implement a
> default behavior and implement it better later. Having theses functions make
> room for future improvements, which is not done with minimal IO.

Guess what? ocamlnet implements all that in a convincing way. Read its
introduction to OO wrappers for I/O:

http://ocamlnet.sourceforge.net/intro/netchannels.html

The signature of Netchannels as reference:

http://cvs.sourceforge.net/viewcvs.py/ocamlnet/ocamlnet/src/netstring/netchannels.mli?rev=1.12&view=auto

Of course, we should not discuss all that, but concentrate on a
reasonable level of abstraction, no matter whether this is a low-level
or high-level abstraction for a certain library.

I would suggest to adopt the names "input", "output", "close_in",
"close_out" of the standard library, as users are already familiar with
them, and this functionality is already quite powerful. Of course, this
is only reasonable for byte channels, not for Unicode channels.

I think we should not meet on the level of character-by-character I/O,
although byte channels and Unicode channels could then share the same
method names. The reason is simple: Users of byte channels don't want to
do char-by-char I/O while users of Unicode channels can accept that. I'm
speaking of the _users_ intentionally, not of the implementors, as the
users will decide which class interface will be successful and which
not. I think the way to go is an adaptor class that translates between
byte strings and Unicode characters, and does the necessary conversions.

Of course, sharing the same method name is possible, in ocamlnet we have
e.g. output_char where camomile has put_char. So the question is whether
this is worth the effort.

As I am the main developer of ocamlnet, I can say that I am willing to
change method names, or define additional methods, when the community
agrees on a certain standard. This greatly improves the interoperability
of the libraries, and is worth the pain resulting from the numerous
follow-up changes in dependent libraries and programs.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners