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!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Musing on defining attributes and the ability to define an "abstract type X"-interface. Date: Tue, 8 Aug 2017 20:12:25 -0500 Organization: JSA Research & Innovation Message-ID: References: <9617c73b-e23e-405b-8544-4d17e7e3ad61@googlegroups.com> <28512bf1-0c2c-400f-a24f-cc7e0eb8a02d@googlegroups.com> <87h8y67trd.fsf@jacob-sparre.dk> <36a1a83d-f3d7-4e3c-827d-addeadc28ccc@googlegroups.com> <202c2f80-ad58-4fac-9fff-e064fed782a9@googlegroups.com> Injection-Date: Wed, 9 Aug 2017 01:12:26 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="23428"; mail-complaints-to="news@jacob-sparre.dk" X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246 Xref: news.eternal-september.org comp.lang.ada:47654 Date: 2017-08-08T20:12:25-05:00 List-Id: "Shark8" wrote in message news:202c2f80-ad58-4fac-9fff-e064fed782a9@googlegroups.com... ... >That is what this proposal is about, not OOP or keyword >"Interface"/"Abstract", >but bringing things together so that the whole current type-system can be >described uniformly in this new manner... and that is the key: UNIFORMLY. No one is going to take this on, or even allow it to be done. It would cause dozens (probably hundreds) of bugs in the Standard's wording, which would have to be fixed down the road. (Just look at the number of bugs that adding preconditions, a much smaller change, caused.) See also my response to Dmitry. It doesn't matter if something is *better* (whatever that means), it matters if it is compatible with the current definition, it matters if the costs to implement it (both in the wording of the language standard and in implementations) are cheap enough, and it matters whether the problems that it will solve are important. The only way to avoid spending all of our very limited time on way-out ideas that may lead nowhere is to very strictly ask for problems that need solving. The string mess needs solving, and preferably without adding Wide_Wide_Open to every I/O unit. No one has any problems for integer types that I know of. >Even you yourself have scratched the surface in recognizing that >[[Wide_]Wide_]String ought to have a "base class" -- though >your solution (ie Root_String_Type) is a specific solution where >if a general solution like this were proffered we could do things >like: have containers with the interface of "array" [ie C'Length, C'First, >etc]. It would be better if arrays had a container interface, IMHO. The whole idea of an array is a rather archaic one, and it would be best if they were simply forgotten about. Moreover, we're only talking about a single character difference (C.Length vs. C'Length). I was trying to solve the only real problem with strings, which is dealing with string literals. Even if you made some sort of overall generalization, you'd still need a special case for strings because you have to deal with string literals. So, I don't see it; in any case, you need to show the problems that are being solved. Lack of uniformity is not a problem, per-se; it would be completely impossible to make a language that was completely uniform. (Tucker used to explain this as "bump under the rug" issues: you can move the bump around, but there is no way to actually eliminate it.) Randy.