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,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 2002:a37:4891:: with SMTP id v139mr16698731qka.172.1581612426172; Thu, 13 Feb 2020 08:47:06 -0800 (PST) X-Received: by 2002:a05:6830:1304:: with SMTP id p4mr14234718otq.327.1581612425754; Thu, 13 Feb 2020 08:47:05 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 13 Feb 2020 08:47:05 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: google-groups.googlegroups.com; posting-host=47.185.239.228; posting-account=zwxLlwoAAAChLBU7oraRzNDnqQYkYbpo NNTP-Posting-Host: 47.185.239.228 References: <2a19cdb1-6f01-4b1d-8597-b6ee21ed60ed@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9d6d22b8-3771-47ac-901f-e593237fe108@googlegroups.com> Subject: Re: Simple Data Endianness From: Optikos Injection-Date: Thu, 13 Feb 2020 16:47:06 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Bytes: 4524 X-Received-Body-CRC: 321737561 Xref: reader01.eternal-september.org comp.lang.ada:58054 Date: 2020-02-13T08:47:05-08:00 List-Id: On Thursday, February 13, 2020 at 9:28:16 AM UTC-6, Dmitry A. Kazakov wrote= : > On 2020-02-13 16:12, Optikos wrote: > > On Thursday, February 13, 2020 at 5:10:44 AM UTC-6, Dmitry A. Kazakov w= rote: > >> On 2020-02-13 10:42, guijarrockGuijarro wrote: > >> > >>> The problem I present today is related to the coexistence between big= -endian and little-endian application data. > >> > >> How low-level representation aspect might be relevant to application d= ata? > >=20 > > If the exchange of app data between 2 or more computers is word-wise bi= nary instead of byte-wise textual, such as via binary-formatted files or vi= a binary-formatted datagrams/byte-streams as payload of networking protocol= s. >=20 > And how whatever protocol encoding format is could to "coexist" (?) with= =20 > another itself (?) >=20 > In any case it has nothing to do with application data as kept in the=20 > memory. Even your facetious example of app-data exchanged in Mayan numerals stored = in GIF images needs to be in DRAM for encoding and decoding the app-data to= other modules of software elsewhere in the app. Implying that the app-dom= ain must absolutely keep a single copy of its data without making any other= copies of that app data is a strawman. There will be user-inteface copies= of substantially the same app-data. There will be file-representation cop= ies of substantially the same app-data. There will be optimized numerical-= processing copies of substantially the same app-data. There will be genera= l intra-app interchange processing of substantially the same app-data. Any= one who thinks that there should be a single copy (or a Draconianly-minimiz= ed quantity of copies) of app-data needs to spend some time studying model-= view-controller software architecture a bit more=E2=80=94or better yet MVVM= , or better yet still VIPER. VIPER takes minding-your-own-business regardi= ng each* app-zone's differing needs regarding each* app-zone's copy/represe= ntation of the app-data to the Nth degree to achieve a wise separation of c= oncerns and in turn to achieve collocation of reference when that is needed= for efficiency in some app-zone that has collocation of reference as its c= oncern. * broadly categorized into 5 buckets, where each contains multiple/numerous= OO class-trees that hand off to each other in disciplined ways: view (V),= presenter (P), interactor (I), entity (E), router (R) https://cdn-images-1.medium.com/max/2000/1*YBRVqOQw0q1a5g1RFP6REQ.png > BTW, supposing the exchange protocol happens to be Mayan numerals stored= =20 > in GIF images. What representation clause we need in Ada for that? When Ada has Mayan numerals and GIF images as 1st-class citizens in the cor= e language (i.e., not even the standard library), then, yes, Ada would need= to have representation clauses for them. Obviously, this would be a major= disincentive to standardizing Mayan numeral and GIF images in the core lan= guage. Perhaps you could submit an AI on an 01 April of some year to see h= ow far the AI gets in the process.