From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id WAA20878; Mon, 26 Apr 2004 22:57:07 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id WAA20058 for ; Mon, 26 Apr 2004 22:57:06 +0200 (MET DST) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.184]) by nez-perce.inria.fr (8.12.10/8.12.10) with ESMTP id i3QKv5jq029406 for ; Mon, 26 Apr 2004 22:57:05 +0200 Received: from [212.227.126.160] (helo=mrelayng.kundenserver.de) by moutng.kundenserver.de with esmtp (Exim 3.35 #1) id 1BIDA0-0006gL-00; Mon, 26 Apr 2004 22:57:04 +0200 Received: from [80.129.114.89] (helo=gate.gerd-stolpmann.de) by mrelayng.kundenserver.de with asmtp (Exim 3.35 #1) id 1BIDA0-0005vB-00; Mon, 26 Apr 2004 22:57:04 +0200 Received: from ice.gerd-stolpmann.de (ice.gerd-stolpmann.de [192.168.0.13]) by gate.gerd-stolpmann.de (Postfix) with ESMTP id B42465816; Mon, 26 Apr 2004 22:57:03 +0200 (CEST) Received: by ice.gerd-stolpmann.de (Postfix, from userid 1000) id 162AEB032; Mon, 26 Apr 2004 22:56:59 +0200 (CEST) Subject: Re: [Caml-list] Re: Common IO structure From: Gerd Stolpmann To: Nicolas Cannasse Cc: Yamagata Yoriyuki , caml-list@inria.fr In-Reply-To: <016401c42bc4$b6438840$19b0e152@warp> References: <00cb01c42afd$7fc1b430$19b0e152@warp> <20040426.221606.71081508.yoriyuki@mbg.ocn.ne.jp> <015701c42b9a$00065730$ef01a8c0@warp> <20040427.002643.78700697.yoriyuki@mbg.ocn.ne.jp> <016401c42bc4$b6438840$19b0e152@warp> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1083013017.8842.327.camel@ice.gerd-stolpmann.de> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5 Date: Mon, 26 Apr 2004 22:56:59 +0200 X-Provags-ID: kundenserver.de abuse@kundenserver.de auth:a6865a839c0178d9aa0ce41878507ea2 X-Miltered: at nez-perce by Joe's j-chkmail ("http://j-chkmail.ensmp.fr")! X-Loop: caml-list@inria.fr X-Spam: no; 0.00; caml-list:01 gerd:01 stolpmann:01 2004:99 cannasse:01 extlib:01 camomile:01 ocamlnet:01 extlib:01 paraphrase:01 behave:01 char:01 char:01 additionnal:01 ocamlnet:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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