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 X-Google-Thread: a07f3367d7,73cb216d191f0fef X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.178.205 with SMTP id bn13mr11081893qab.3.1366380604742; Fri, 19 Apr 2013 07:10:04 -0700 (PDT) Path: ef9ni4645qab.0!nntp.google.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!News.Dal.Ca!news.litech.org!news.etla.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Is this expected behavior or not Date: Thu, 11 Apr 2013 09:59:18 +0200 Organization: cbb software GmbH Message-ID: <1o34nhpfuy6yl$.2orlukd1elr7.dlg@40tude.net> References: <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> <8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: FbOMkhMtVLVmu7IwBnt1tw.user.speranza.aioe.org Mime-Version: 1.0 X-Complaints-To: abuse@aioe.org User-Agent: 40tude_Dialog/2.0.15.1 X-Notice: Filtered by postfilter v. 0.8.2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Date: 2013-04-11T09:59:18+02:00 List-Id: On Wed, 10 Apr 2013 17:07:57 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:8bj2k30k7i19.w7ehsldwbf7x.dlg@40tude.net... >> On Tue, 9 Apr 2013 18:24:29 -0500, Randy Brukardt wrote: > ... >>>> Why there should be many? >>> >>> If you've got operations like "+" or "*", you'll have a lot of functions >>> returning objects of the type. That's a bad idea for the reasons I >>> mentioned. >> >> You have + and * of GUI objects? That is weird. Anyway if you have >> arithmetic upon a hierarchy how the compiler is supposed to deduce >> implementations for derived types? > > Tagged types and extension is used for more than just GUIs. Tagged types are useless when arithmetic operations get involved. It does not work with present design, because type hierarchies are not handled for such operations. > The compiler shouldn't have trouble with inheriting implementations type Real is tagged record Value : Float; end record; function "+" (L, R : Real) return Real; type Complex is new Real with record Img : Float; end record; How is the compiler supposed to inherit "+"? >> You don't make language design dependent and promoting bad practices. > > If you are starting with a blank page, you're right. If you are building on > 30+ years of practice, even "bad practice" has to be taken into account. Nonsense. Bad practice is bad. Longer it lasts bigger is the damage. > This is one of the reasons that the language you're suggesting really has to > be different than Ada. We already discussed that. I want to preserve Ada semantics. It is you who wants completely change the way string types are used in Ada. >>> That isn't very likely to >>> happen. The only way to define these conversions would be through a >>> Wide_Wide_String intermediate - the net effect is that the conversions >>> will be quite expensive and you would never, ever want to use such >>> implementations. >> >> This is exactly the overhead of doing this using the infamous unary plus >> operation. I don't understand the point you are trying to make. You don't >> want to override for custom types, you don't want automatic conversion as >> too expensive. There is no third way. You want to apply explicit >> conversions at all call points? This is exactly the solution you declared >> inefficient. It not only inefficient, it is extremely error prone and a >> major overhead for those unfortunate who have to use the package defined >> in such manner. The compiler rejects a program. What you do? Erratically >> place unary pluses before all arguments? But that is invisible. Actually some >> hundred of them are already visible. For each of them the compiler spits >> some garbage error messages on you. But the right one you need is not >> visible. Were was it declared? Was it declared anywhere? Have fun! > > You're confusing expensive *implicit* operations with expensive explicit > ones. I don't care that an explicit type conversion is expensive -- you > wrote it, you meant it, and you can see the consequences -- it's right there > in the source code. Right, I don't care about performance I care about usability of the packages. Only when performance becomes a problem I address that. But I never let performance issues to cripple my design. But if performance is your concern, you must be the first to go for multi-methods, because this is the only way to define type-specific operations and to have different representations for different members of the hierarchy. Your proposal was to render all strings as Wide_Wide_String. And you tell me about efficiency? > For instance, I tend to write out the entire name of the conversion between > string and unbounded string: > > Ada.Text_IO.Put_Line (Ada.Strings.Unbounded.To_String (My_Object)); Hideous. What kind of information this mess should convey to the reader? 2/3 of it is noise. My_Object is a string, why Put_Line does not handle it? -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de