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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM 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!postnews.google.com!50g2000hsm.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Wed, 26 Sep 2007 14:31:01 -0700 Organization: http://groups.google.com Message-ID: <1190842261.235691.298520@50g2000hsm.googlegroups.com> References: <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> <1190497995.498679.119190@19g2000hsx.googlegroups.com> <1mw3qju08q8uj.sgzht7ld9ydc$.dlg@40tude.net> <1190579805.451187.71140@d55g2000hsg.googlegroups.com> <1i8ksr774bjbj.vpmnx3c0i9qz.dlg@40tude.net> <1190646125.024072.310020@19g2000hsx.googlegroups.com> <1r9s9v6pcjifl.vp4ktk0unpd1.dlg@40tude.net> <1190753631.240548.101820@19g2000hsx.googlegroups.com> <1hlqzsdiq2hxf$.nni5xz67fc13.dlg@40tude.net> NNTP-Posting-Host: 85.3.107.199 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190842261 9525 127.0.0.1 (26 Sep 2007 21:31:01 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 26 Sep 2007 21:31:01 +0000 (UTC) In-Reply-To: <1hlqzsdiq2hxf$.nni5xz67fc13.dlg@40tude.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 50g2000hsm.googlegroups.com; posting-host=85.3.107.199; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2148 Date: 2007-09-26T14:31:01-07:00 List-Id: On 26 Wrz, 12:42, "Dmitry A. Kazakov" wrote: > >> 2. This degenerate is anyway inviable, as you can call primitive operations > >> from non-primitive ones. > > >> 3. There already exists a type that has the desired property of > >> non-dispatching, it is T (specific). > > > 2. and 3. are inconsistent. > > No, because the specific type does not kill primitive operations it only > freezes them. Not much. I can recover T'Class from T, as in the example from previous post. [...] > > procedure Initialize (X : in out T) is > > begin > > Put ("P.Initialize for T"); > > New_Line; > > Put ("-> doing some operation with the object"); > > New_Line (2); > > Dispatch (X); > > ^^^^^^^^^ > The problem is here. Initialize converts the object X to T'Class. Bingo. Now you might want to explain to me how is this possible if type of X is specific T. How is it possible to recover T'Class from T? Apparently the type I see in Initialize is somehow decoupled from the type of the object itself. In other words, what I see in Initialize is not the whole "truth" about the object. The truth is within the object itself, not in the parameter of Initialize, and with appropriate question I can get the full answer. But this only means that T does not really fully determine X. With appropriate application of the notion of view this is easy - as far as I'm concerned, the object is T'Class, but Initialize sees only the T view on it. But you claimed that views are not needed. Try to explain this without reinventing views. :-) > The > result of this conversion would be wrong if Initialize were a hook on the > constructor of T. But it isn't. So formally everything is OK. Initialize is > a hook on the constructor of T'Class which is officially constructed, no > matter that S's Initialize wasn't called. None of Initializes was called before T'Class was complete. That's the problem. It's entirely reversed, leading to untyped mess. > Note that the case you presented is just a variant of the more general > problem called "re-dispatch." As your example nicely illustrates, > re-dispatch is inherently inconsistent. I'm not sure whether this is inherent, or just a consequence of the fact that T'Class is formally complete before it's initialized. > C++ openly uses re-dispatch, Ada does it through the backdoors like above. Note that C++ protects the programmer from *this* type of mess. > > I want to register T'Class, but I don't want to involve those who > > derive from T. > > Sorry, but T'Class includes them, your design is inconsistent with that. > Can you explain where could it be useful? Abstract factories perhaps? I want to set up a framework for the abstract factory design pattern. The base types and registry are part of the framework and the user provides the concrete factories. The base types register the factories in the registry so that later the user can request them and get concrete behaviour. This is cool and clean only if the registry mechanics is encapsulated within the framework, so that the user does not have to care about it in his own constructors - but this is possible only if the base type can register T'Class, not just T. But as we've seen, I can recover T'Class from T, so I can do this anyway. :-) > >> You could say it simpler: Children and Adult are different types. Period. > > > They are both in Human'Class. You try to escape the problem instead of > > solving it. > > I don't see any. If they are in Human'Class <=> they have the behavior of. > A client would use that behavior. Why do you need to change anything? A client can ask for the additional interface after discovering the concrete type. > > A wrong solution is exploited in the example above. > > You have switched the subject from the language to its [ab]use. That Ada > does not solve the construction problem is clear to me. But that is not an > inconsistency, it is an incompleteness. OK. Name it as you want. I don't like it anyway, no matter what's the name. :-) > > But so-called "constructor functions" will not solve this problem. > > Certainly. I think we, two! (:-)) agree that Ada should have a better > construction model with user insertions. The next step would be to convince > others, and to learn for the mistakes made by C++. Yes. So what are those mistakes actually? :-) I don't claim there are none. -- Maciej Sobczak http://www.msobczak.com/