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!mx05.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Sun, 7 Apr 2013 09:00:16 +0200 Organization: cbb software GmbH Message-ID: References: <1u72u7h5j4jg3$.wlxmaltyzqik.dlg@40tude.net> <1gnmajx2fdjju.1bo28xwmzt1nr.dlg@40tude.net> <3gv2jwc95otm.pl2aahsh9ox8.dlg@40tude.net> <1gkxiwepaxvtt$.u3ly33rbwthf.dlg@40tude.net> <1fmcdkj58brky.bjedt0pr39cd$.dlg@40tude.net> <1bj564vat3q1j$.1s4d00rlzx4ux$.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: rHWOzyHApalsT5sEUcbvVQ.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:14904 Date: 2013-04-07T09:00:16+02:00 List-Id: On Fri, 5 Apr 2013 20:20:58 -0500, Randy Brukardt wrote: > Automatically converting Wide_String into String is > unsafe as it loses information, and that's even more true once you start > thinking about other character sets. All existing character sets are subsets of Unicode. String could be an Ada subtype of Wide_String. Only difference is in the representation. Even more this applies to encoding. Clearly encoding has nothing to do with the content of a string. > And that suggests that the entire idea is bad. Indeed, that indicates that > all OOP is bad because it destroys type-checking. Perhaps I should forget > that I ever heard of it?? You conflate type checking with representation checking. There is no need to check how a string is represented. > But in any case, there are two important differences here: single operand > operations vs. multiiple operand operations, This difference is only important because the type model you deploy cannot handle the later. There should be something wrong with the model then. >> Now this: >> >> function Get_Text (Control : Edit_Box) return Root_String_Type; > > First, this is illegal because Root_String_Type is abstract, and you can't > have a function returning an abstract type. > > Second, you can't implement that in Claw (or Ada), because the Edit_Box is > an "in" parameter and you need to modify some of its components in order to > deal with the state changes of the edit box. > > So you have have to have something like: > > function Get_Text (Control : in out Edit_Box) return > Root_String_Type'Class; You will need explicit conversions wherever you use Get_Text: X : UTF8_String := Box.Get_Text; or Open (Box.Get_Text); >>>>>> The only pattern that sometimes works is recursive cascaded dispatch. >>>>>> That is when you make one argument controlled and another class-wide. >>>>> >>>>> Gosh, that's what I was talking from the beginning. >>>> >>>> It works only with dyadic operations, procedures or else functions >>>> returning an alien type. >>> >>> Which is 95% of the cases that you would want. >> >> No more than 20-30% actually. > > OK, it's 95% of the cases that occur in actual practice, They don't occur in practice because the language simply does not support it. As for cascaded dispatch, it is incredibly error prone. Note that cascaded dispatch involves complementary operations, e.g. let you dispatch on T1= T1) Yet another issue is preventing recursion of cascaded dispatch. You need a whole set of internal operations with additional parameters to keep track of re-dispatching calls. It is exceptionally difficult to implement already in such simple case as <. >>> the Ada 95 effects make it absolutely >>> necessary to avoid functions returning a controlled type, else creating >>> extensions is so hard that no one will do it. >> >> I don't know where you get that idea. I never had any problem with >> abstract factories. > > Well, I have. As I previously explained, the abstract routines and functions > in the Claw Builder root types make it so time-consuming to create an > extension (the last one I did took around 20 hours to write, and even then I > never finished it) that it's impractical to do so. > > If you have only one such routine, Why there should be many? Anyway, if you know how to create such function, you make it class-wide. If you don't know, nobody knows. It must be overridden and the compiler tells you so. There is simply no problem with that. >>>> Not at all, the compiler is free to choose, so it must. [I don't consider >>>> schizophrenic compilers choosing one way and doing in another. That does >>>> not work with any model.] >>> >>> It doesn't work for portability reasons for some compilers to call Adjust >>> during the evaluation of parameters and other compilers to not call >>> Adjust. >> >> When the type neither specified as either by-reference nor as by-value, it >> shall be exactly this way. I don't understand why this is relevant. >> >>> It would make performance wildly variable and possibly cause bugs (if the >>> program unintentionally depended on one or the other. >> >> Yes, the language permits compilers implemented poorly, and? > > This has nothing to do with compilers. It has to do with *poorly designed > programs*. It's certainly true that a program that depends on by-copy or > by-reference passing is wrong; the compiler should be free to choose. But > this is an undetectable error. And bringing Adjust into it makes it much > worse, because it's easy to write code that doesn't work if Adjust is called > (you probably can get infinite recursion that way). Are you saying the copy constructors (Adjust) are broken in Ada? They are to me too. Fix them. >>>>> It strikes me that the model of stripping tags means that type conversion >>>>> of an object to a class-wide type would effectively change the tag (if the >>>>> routine was inherited or called by a conversion of an operand). >>>> >>>> Yes, re-dispatch is a broken thing. Don't do it, because it is ambiguous >>>> in general case when objects do not have an identity. By-copy scalar types >>>> are such things. There is nothing which could distinguish Integer 13 from >>>> Long_Integer 13 except the context. Once you dispatched that information >>>> is lost. There is no way back. > > Here you are saying that you can't redispatch because you insist on a model > that doesn't allow it. No model exist which would allow re-dispatch on scalar value. Like no model exist where 2+2=5. >>>>> That would >>>>> mean that the behavior of such a conversion would be very different for >>>>> an untagged type and for a tagged type. >>>> >>>> Not different. It is just so that tagged types per design have type >>>> identity. Other types simply don't have it. >>> >>> Objects of limited types are always assumed to have an identity; >> >> No. E.g. task and protected types lack type identity. Only tagged types >> have type identity. >> >> Note that type identity /= object identity (e.g. machine address where the >> object resides). > > I don't think that they ought to be separated. If you have object identity, > and every object has a nominal type, it does not make sense to lose that > information. Nothing is lost. You forgot that the parameter was passed by copy, as required by the type, which was by-copy. It is another object in there. Its identity is obviously not the identity of the origin. How could it be otherwise? >>>> You want to derive each string type straight from Root_String. >>> >>> Yes, or from related ones. There is no significant value to doing anything >>> else - as you point out, if you can inherit the operations, the >>> representations have to be compatible. So there is nothing useful you can >>> do with multiple levels. >> >> Encoding! > > You have to reimplement *every* operation for a new representation (in your > model as well as in existing Ada). Most bodies will be inherited per composition with conversion. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de