From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,62ab88cac7a1dbb
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,ASCII-7-bit
Received: by 10.180.81.136 with SMTP id a8mr70791wiy.3.1348190011357;
        Thu, 20 Sep 2012 18:13:31 -0700 (PDT)
Path: 
 q11ni3492521wiw.1!nntp.google.com!feeder1.cambriumusenet.nl!feeder2.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.84.MISMATCH!newsfeed.xs4all.nl!newsfeed5.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border3.nntp.ams.giganews.com!border1.nntp.ams.giganews.com!nntp.giganews.com!newsreader4.netcologne.de!news.netcologne.de!newsfeed.straub-nv.de!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: Gnat Sockets & Streams
Date: Sat, 15 Sep 2012 20:27:21 +0100
Organization: A noiseless patient Spider
Message-ID: <m2r4q3krxi.fsf@pushface.org>
References: <201209142101005065-rblove@airmailnet>
	<6owmaht6knzo.brd5acsbbu7j$.dlg@40tude.net>
	<m2vcffkymt.fsf@pushface.org>
	<1ttqhbx9n4s95.16m595tl7m69p$.dlg@40tude.net>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="a9272c9c584810f74e3f95ce46cbeceb";
	logging-data="22460"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18h5Dq3qxgzBvjbUnOC6LumZ4FDlmAJoS0="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:4EmuHZpQBN+/r7jiz5aGI0edFL8=
	sha1:fxS/agDCdUuDIgB4+tjU3YNpCzg=
Content-Type: text/plain
Date: 2012-09-15T20:27:21+01:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 15 Sep 2012 18:02:34 +0100, Simon Wright wrote:
>
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>>> 2. As with any I/O you should honestly implement all layers of the protocol
>>> at hand. Don't try shortcuts like stream type attributes, representation
>>> clauses etc.
>> 
>> The stream type attributes may well be OK, and (as above) if you have
>> the same compiler either end you will probably be OK. It's quite another
>> matter if your Ada has to talk to someone else's C.
>
> I argue that this is not solid engineering. Even if two Ada programs
> are to communicate, the protocol must be fully specified first. The
> implementations must conform that specification. If a stream attribute
> indeed implements the specification, fine, the code should document
> that and explain why. What I am strongly against is that sort of
> upside-down design, when people implement something first and then
> declare that the would-be protocol is what the stuff accidentally
> happens to do.

Well, I'd have thought that the it would be OK to say

* we need to transfer <data>
* we need a protocol, would <what we know stream attributes do> be OK?
  - yes, go with stream attributes
  - no, declare a data-specific protocol

because I doubt that, for instance, a protocol for strings would first
pass the lower & upper bounds! you'd much more likely pass the
length. So the stream attributes wouldn't meet the predefined protocol;
and you've committed to work that might not have been necessary.

But I do agree that you have to be sure that the stream attributes will
suffice.