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!aioe.org!.POSTED.yTvCNOh9TRCAIcX40YItlQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Private extension of a synchronized interface Date: Sun, 17 Feb 2019 17:28:37 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <51243c9b-baba-43ad-b227-fe39c045d403@googlegroups.com> <70d5022b-963d-4ee5-b45d-e9c6a28037eb@googlegroups.com> NNTP-Posting-Host: yTvCNOh9TRCAIcX40YItlQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:55548 Date: 2019-02-17T17:28:37+01:00 List-Id: On 2019-02-17 16:36, Jere wrote: > On Sunday, February 17, 2019 at 9:52:42 AM UTC-5, Dmitry A. Kazakov wrote: >> On 2019-02-17 14:46, Jere wrote: >>> On Sunday, February 17, 2019 at 4:50:24 AM UTC-5, Dmitry A. Kazakov wrote: >>>> >>>> But synchronized interfaces are totally bogus from the software design >>>> POV. It is a pure implementation aspect exposed. Why do you care? >>>> Aggregate a protected object and delegate primitive operations to it. >>>> >>> >>> That's what I am doing as my own solution. I was intrigued with the code >>> above as an alternate solution because it could potentially give a >>> compile time indication that a procedure was a protected operation (as >>> opposed to me relying on simply providing that via comments). >> >> Given to who? The compiler knows already, the user should not care. It >> is an implementation aspect which simply does not belong here. >> > The compiler cannot always tell depending on how and where you call buried > protected operations. But it is the reverse. You do not promise not to implement it as a protected operation, you promise to do it protected straight away! > I always prefer compile time catching over run time catching. It is a weaker precondition, nothing to catch at all. >>> A delegate non protected procedure has to rely on the comment. >> >> There is no contract that could require it protected. It is a property >> of the object/task and no property of an operation. You could not do >> anything with a task or protected object that would not resolve into a >> protected action anyway. > > Protected procedures/functions/entries are particularly heavy operations. > I don't know if you generally work in low level embedded environments, > but being able know and plan for that can be very critical. It can > change how you approach your design. When you work in systems where > your system clock is 1-4MHz, timing of operations does start to matter. Again, you are talking about the reverse: type T is not synchronized but still limited interface; -- (:-)) and there is no actual use for this either. As a general note, "heaviness" is non-functional, ergo cannot be in a contract. >>> However, I honestly >>> wanted to know why Ada allowed one to setup the private extension but not >>> allow you to actually provide the functions (or if this was a GNAT issue or >>> if I was just not using the right syntax). So the reason I care was a >>> thirst for knowledge of how things work. >> >> Ada 2005 stuff, most of it makes little sense to me. It was some >> halfhearted attempt to unite tagged types with tasks and protected >> objects with no desire to actually do that... >> > I'm just curious if or why the process was stopped half way instead of > abandoned or completed (again that is assuming I didn't use the wrong > syntax, in which case it's simply that I'm structuring the syntax wrong). I think nobody had an idea how to make protected objects/tasks extensible. How would you override entries of a task buried in accept statements of the parent's task body? Javaesque interface with a one-set inheritance seemed simple to do. It is no half way, you basically not even left the house. > I don't really need to marry them with tagged types. I do appreciate > the ability to dispatch over a group of related but different tasks > much more easily and the interfaces give that. The way that Ada chose > to implement interfaces is one of many ways (not all of which would > have required tagged types). Yet another half measure. If only tagged types may have classes then tasks must be kind of tagged. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de