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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: 'Protected' abstract subprograms Date: Sun, 12 Jan 2014 11:22:19 +0100 Organization: cbb software GmbH Message-ID: References: <839fee13-2743-49f6-a7f3-f95578386201@googlegroups.com> <14q37tx4uvbw4$.ua9oe7a01emv.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: SACMYH1Y5pIOuwuZn7n4NQ.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Xref: news.eternal-september.org comp.lang.ada:18156 Date: 2014-01-12T11:22:19+01:00 List-Id: On Sun, 12 Jan 2014 11:19:41 +0200, Niklas Holsti wrote: > (I said I wouldn't, but here I go...) > > On 14-01-11 21:35 , Dmitry A. Kazakov wrote: >> On Sat, 11 Jan 2014 15:42:39 +0200, Niklas Holsti wrote: >> >>>> * When you dispatch in a body of an operation that means that the body is >>>> valid for more than one type. Many types = class. Operation for all class = >>>> class-wide operation. >>> >>> Yes, but "many types" is not the same as "all class". >> >> Per design pattern it is all class. Anyway, it is certainly not the >> singleton type specified in the pattern, because that is type is abstract. >> >> But of course, if you want to propose changes in the language which would >> allow specification of narrower subclasses for such cases, it would be most >> welcome. > > As I see it, it is you who are proposing a change: you say that > redispatch should never be used, so you are proposing a reduced Ada > language which does not *have* redispatch. Firstly, when I say that re-dispatch should not be used, that is not same as proposing to remove it = technically, to disallow view conversions in the bodies of primitive operations. Though if you asked, yes I would do that, providing Unchecked_Class instead. Secondly, it is not reduced. On the contrary, if you want to be able to re-dispatch then you must reduce the language by limiting dispatching operation to strictly by-reference types and then reduce these types to certain representations that would contain the parent's type representation. It is a very serious and quite non-Ada constraint as it meddles with representations. Thirdly, I merely pointed out that if we agreed that re-dispatch refers to a class, which in your opinion cannot be spelt in the language, then, logically, you should, if you wanted to keep re-dispatch, change the language so that this class could be properly specified. Of course, carefully observing the result of such an extension, you could note that it would not be re-dispatch anymore because the operation in question would now act on some class rather than a specific type. Well, that is the point. Re-dispatch is fundamentally wrong, which does not mean that the functionality is wrong. You can keep the functionality, but not spell it as re-dispatch. >>>> Re-dispatch breaks this model and effectively makes your design >>>> un/weakly typed. >>> >>> I don't agree, because my conceptual "model" is different. Your model is >>> stronger (more specific) than mine, which paradoxically means that it is >>> easier to break :-) >> >> Wouldn't that be arguing against strong typing? > > Your concept of classes and types is stronger (more specific and > limiting) than what Ada provides -- in effect, I used nothing but class = set of types (a closure of, being precise). How is it stronger than Ada's concept of class/type? I thought it was the concept Ada deployed. > you have certain design > rules which limit you to an Ada subset without redispatch. merely strongly typing. Compare it to Unchecked_Conversion and argue against the design rule to avoid Unchecked_Conversion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de