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=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,1a52c822fc0dbb23 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!proxad.net!213.200.89.82.MISMATCH!tiscali!newsfeed1.ip.tiscali.net!newsfeed00.sul.t-online.de!newsfeed01.sul.t-online.de!t-online.de!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail Newsgroups: comp.lang.ada Subject: Re: Rational for not making cursor tagged in Containers From: Georg Bauhaus In-Reply-To: References: <1176998738.656903.141250@q75g2000hsh.googlegroups.com> <1177010938.200523.325290@p77g2000hsh.googlegroups.com> <1a8y2vakorfhx.225uqh4hifpd$.dlg@40tude.net> <1xmzi7newnilp.23m3zze8h9yi.dlg@40tude.net> <1177066583.5876.30.camel@localhost.localdomain> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: # Message-ID: <1177080147.5876.87.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.8.1 Date: Fri, 20 Apr 2007 16:42:27 +0200 NNTP-Posting-Date: 20 Apr 2007 15:40:48 CEST NNTP-Posting-Host: 02d84178.newsspool3.arcor-online.net X-Trace: DXC=X]3Ei:dUNl;]E=H1Q9`787McF=Q^Z^V384Fo<]lROoR1Fl8W>\BH3Y2G]f>Z2[06E8A:ho7QcPOV3n9Lne>CkJ31b0PZk2Ni1J> X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:15150 Date: 2007-04-20T15:40:48+02:00 List-Id: On Fri, 2007-04-20 at 12:39 +0200, Dmitry A. Kazakov wrote: > On Fri, 20 Apr 2007 12:56:23 +0200, Georg Bauhaus wrote: > > type Foo is interface record ... > > ... There is no > > way of knowing whether reading or writing a record component will > > just move some bits, or try to compute the first prime number of > > the 1969 lottery on the way. > > And you claim to know it. Always? With all possible pragmas applied, > including Pack, as well as representation clauses like for X'Address use > ...? The practical difference between a simple record and a programmer- defined record interface implementation is a set of fixed rules in the first case and full (sub)programs in the second case. > As for me, I don't know it in 90% cases, and in 99% of these, I just > don't care. Right, I assume you don't care to known what an assignment to a record component does because you either rely on the thing being a "sufficiently normal" data component or you can trust the authors of the program and assume they haven't introduced an overly ambitious algorithm for Adjust that would let your application hang for a while. > BTW, Ada has private types from the day one. If the type in question is private, there is nothing to argue about. But your record type construction interface wasn't private; and it didn't announce that Mumble isn't just a record component. To emphasize: I don't want to loose comparatively simple building blocks (records) just because some smart programmers can build similar things (implementing record interfaces) with more effects. I'm not forced to provide get {} and set {} in C#, and neither assigners in Eiffel. > > And, considering Controlled, forcing *all* types to be derived > > from this base suffers from the same effects for the same reason. > > Because multiple-inheritance is *the* answer. You need not to force anybody > to anything if an interface (and an implementation of) can be added later. This is where it becomes dangerous, I think. Suggesting that programmers can implement "linguistic interfaces" forces programmers to be language designers, profiting from decades of language research, compilation technology, etc. etc.. > But more things you have hard-wired > in the language, more complex it becomes for everybody, you, me, the > compiler vendor and the Pentium. If the hard-wired features of a language don't suit your problem, or your solution, it might become a complex issue to work around the language. Using a language construction language (sic) that suits your problem solution will be a more pleasant experience. But for whom? A reader will have to acquire complex language construction language rules; just as look-at-my-neat-domain-language-macros are both clever and not recommended in the general case (by Graham). > > Not every programming team consists of real or even wannabe > > language designers. But who else has even got a chance of knowing > > what they are doing to a larger program when implementing the > > concept of record? > > Why they are allowed to implement a concept of task, Uh, what do you mean? Ordering entry calls? Specifying rules of conditional acceptance? In the more common case, I find that much better than using a language that "gives you the freedom to roll your own" tasking. > Where do you draw the line? For a general purpose language, I draw the line where the programmers would otherwise be forced to fiddle with the tiny bits usually done by compilers. The operations of private types are not tiny bits, but forcing plain record component assignments to be full subprograms should not be the default in Ada.