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: 103376,dbcfe2b0a74da57e X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!eweka.nl!lightspeed.eweka.nl!83.128.0.11.MISMATCH!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!dekendi.nntp.kabelfoon.nl!npeer.de.kpn-eurorings.net!npeer0.kpn.DE!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Inherited Methods and such Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <1190039166.449906.15070@g4g2000hsf.googlegroups.com> <1190060534.958182.51800@d55g2000hsg.googlegroups.com> <87tzptuhku.fsf@ludovic-brenta.org> <1190125656.071013.303640@22g2000hsm.googlegroups.com> <1ds7l1l7oeyrx.1cpsvrpkikour.dlg@40tude.net> <1190147965.676457.123000@d55g2000hsg.googlegroups.com> <1co37tau98gct.axsglmqh0xu9$.dlg@40tude.net> <1190213376.707449.146640@g4g2000hsf.googlegroups.com> <1fl2wnziigxfd.1fjbag2hh8sbc$.dlg@40tude.net> <1190239986.762473.204290@k79g2000hse.googlegroups.com> <1rw45b3rmvmcr$.1df4wst5oknbl$.dlg@40tude.net> <1190296353.624737.150940@y42g2000hsy.googlegroups.com> <11m13st1f92kf$.m8s6y8mc8ebk.dlg@40tude.net> <1190321119.206313.65290@57g2000hsv.googlegroups.com> <1190408526.100291.265040@50g2000hsm.googlegroups.com> <9ukf2wtqjs0q$.iuijmal4x56b$.dlg@40tude.net> <19ie8rfpiitdx$.i2sz3r6uj66w.dlg@40tude.net> Date: Wed, 26 Sep 2007 14:42:30 +0200 Message-ID: <1bcgc7x7hppwi$.qmyz4cv1ty8f$.dlg@40tude.net> NNTP-Posting-Date: 26 Sep 2007 14:36:54 CEST NNTP-Posting-Host: a6d841cc.newsspool2.arcor-online.net X-Trace: DXC=4o7[d>4;EbS@@RW1FjIB5SA9EHlD;3YcR4Fo<]lROoRQ<`=YMgDjhgRaQbJAHLHRUU[6LHn;2LCV^7enW;^6ZC`TIXm65S@:3>_dUP\DgTLlU[ X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:2140 Date: 2007-09-26T14:36:54+02:00 List-Id: On Tue, 25 Sep 2007 16:02:55 -0500, Randy Brukardt wrote: > "Dmitry A. Kazakov" wrote in message > news:19ie8rfpiitdx$.i2sz3r6uj66w.dlg@40tude.net... > That's what I tried to do with Janus/Ada, and it doesn't work in all cases. Probably one should give another try and consider the cases where it appears not working. Maybe they indicate language design problems to fix. BTW, back in the time I wrote compilers, I noticed that the number of cases tend to geometrically explode. At some point it was impossible to keep everything in the head. I played with an idea of some metalanguage to describe all the mess and to generate a part the compiler dealing with semantic analysis and intermediate code from a [semi-]formal description. Something equivalent to what grammars do for the syntax analysis. The problem is that there existed no formal framework comparable with formal grammars to describe the types system. (UML is a joke, IMO). I am quite outdated with compiler design, maybe somebody already did that thing. >>> Note that this is very similar to the reasons that Ada cannot have "real" >>> user-defined assignment; it's not possible to divide an assignment into >>> components managed separately. >> >> Same as above. Moreover it would be probably possible to make the old LHS >> visible in the hook computing the constraints. > > No, you can't have visibility on both objects in a hook routine, because > there are cases where one side or the other does not exist. You have to > define three sets of hooks, which would greatly increase the chance of > errors and probably would be too complex for most to understand. But it is necessary to have three different hooks when dealing with a class-wide object of an unconstrained type. Maybe even more, because of the rules about composition of the constraints. There are three independent hierarchies involved: 1. A hierarchy of constraints (discriminants added/overridden/removed) 2. A hierarchy of components (record extensions) 3. A hierarchy of inheritance (class) > The problem doesn't exist if your language doesn't have disappearing > components, and I would be much more likely to try to approach the problem > from there. But that wouldn't be Ada. I am not so sure. IMO, the complexity comes from the hierarchies above. Whether within one of them (the hierarchy of components) items get added or removed is a detail. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de