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=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!feeder4.usenet.farm!feeder3.usenet.farm!feed.usenet.farm!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!85.12.16.69.MISMATCH!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer03.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!fx08.fr7.POSTED!not-for-mail Subject: Re: protobuff for Ada Newsgroups: comp.lang.ada References: <177bddd8-297e-4c5f-85aa-31cd694e68b4@googlegroups.com> From: Per Sandberg User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Message-ID: X-Complaints-To: abuse@usenet.se NNTP-Posting-Date: Tue, 01 Jan 2019 08:05:40 UTC Organization: usenet.se Date: Tue, 1 Jan 2019 09:05:38 +0100 X-Received-Bytes: 2945 X-Received-Body-CRC: 2169951832 Xref: reader01.eternal-september.org comp.lang.ada:55147 Date: 2019-01-01T09:05:38+01:00 List-Id: Well From my perspective absolutely biggest flaw with technologies like protobuf is: * Its backed by a large corporation. * The technology is well known. * 99.9% of the programming population think that they are the salvation to serialization. * The licensing is open. And on top. * The are significantly more then one project where the lack of protobuf support has ruled out Ada as implementation technology. /And my intent was to eliminate at least the last points even if the technology is inferior. /P On 12/29/18 12:05 PM, Dmitry A. Kazakov wrote: > On 2018-12-29 06:53, Shark8 wrote: > >> Though, it should be noted that ASN.1 is *probably* the better >> technology in cases where ProtoBufs are being considered: >> http://ttsiodras.github.io/asn1.html > > Sorry to disappoint you in this festive time, but this approach has the > same fundamental flaw as prepared SQL statements do. You have to bind > native Ada objects to protocol/serialized/persistent objects forth and > back. This does not work well in practice. In fact, it barely work at > all considering the overhead and hazards of type conversions. > > A different approach is Ada's representation clauses which describe both > objects same. Beyond simple textbook cases that does not work either. > > The best practical method so far is using manually written stream > attributes. Unfortunately it has shortcomings too: > > 1. Reuse is limited and composition is unsafe because stream attributes > are non-primitive operations. > > 2. Introspection is almost non-existed. Only tagged types could have it. > > 3. No support of error handling and versioning. Though it is possible to > do manually that is extremely error-prone and totally lacks static > verification when the number of test cases is huge to potentially > infinite. Even worse, the offending cases do not show up in a normally > functioning system. So, when detected, it is always too late. > > P.S. Needless to say, the problems 1-3 fully apply to other two methods > as well. > > P.P.S. And nothing was said about referential and recursive types... >