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!news4.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool3.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: <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> <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> Date: Wed, 26 Sep 2007 12:42:05 +0200 Message-ID: <1hlqzsdiq2hxf$.nni5xz67fc13.dlg@40tude.net> NNTP-Posting-Date: 26 Sep 2007 12:36:28 CEST NNTP-Posting-Host: b14fb19c.newsspool3.arcor-online.net X-Trace: DXC=[X`dY>jble3i6K;>iZ]763McF=Q^Z^V384Fo<]lROoR1^;5]aA^R6>2nA;SO3Eo^o>[6LHn;2LCV>7enW;^6ZC`4IXm65S@:3>?Ka>F``?SYH4 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news2.google.com comp.lang.ada:2137 Date: 2007-09-26T12:36:28+02:00 List-Id: On Tue, 25 Sep 2007 13:53:51 -0700, Maciej Sobczak wrote: > On 24 Wrz, 21:20, "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. Each primitive operation has a body for a [non-abstract] specific T. Each primitive operation has a body for T'Class. These bodies are different. The latter has a dispatching switch that selects to one of the former bodies. This is BTW another reason why T and T'Class are necessarily different types. >> You are in an unresolvable contradiction by trying to mix class and its >> truncations. It is untyped, just because mixing types in untyped. Ada 95 >> solved that by naming the truncation as T and the class of as T'Class. The >> rest was easy. > > Yes. Like here: > [...] > 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. 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. Your expectations about Initialize were wrong (the problem is that an average programmers would likely have similar expectations. So, train people ... rather a C++ approach, but anyway.) (Separation of T and T'Class is only the first necessary step. It would not automatically make "Ada with constructors" consistent.) 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. This was my point here in c.l.a. and in comp.object for years. C++ openly uses re-dispatch, Ada does it through the backdoors like above. That has to be fixed. >>> Let's say I want to register my new object from T's constructor in >>> some map or somewhere. I don't want to hook to complete T'Class, >>> because I cannot force users deriving from my T to call be back so >>> that I can register. I want the registration process to be >>> encapsulated and invisible and I want to do it from T's constructor. >>> If you restrict the possibility to use T'Class inside the constructor, >>> you have to way to register T'Class reference/pointer from T's >>> constructor. Too bad. >> >> I don't understand your example - if you don't derive from T, its >> constructor will not be called. What do you want, to register objects of >> the type T or objects of the type T'Class? Answer this and you will know >> from where to do the registration of what. > > 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? I still doe not understand the setting. Do you have method disallowing in mind? >> 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? >>>> My point is, a view is just a new object of a *new* type. >> >>> It does not have to be, but I find it acceptable except that I don't >>> think you need a *new* type for them. >> >> We need it to prevent infinite recursion. More generally, here the >> behavioral principle applies: if there is a difference between object and a >> reference to => that should be observable through the behaviors of => they >> have different behaviors => they have different types. > > What if they don't have different behaviors? What for have you introduced "views," then? (:-)) >>> Control question: what is the identity of the view? :-) >> >> There is nothing special in identity. A view can have many identities: >> >> 1. The name of the view >> 2. The type of the view >> 3. The target if the type of is comparable >> 4. The tag of the view if it is polymorphic >> 5. The tag of the target if that is polymorphic >> ... > > 6. The identity of the target. Only if that has the identity you are looking for. The target can have or miss many identities. >>>> Ada is consistent because Initialize is not a constructor. It washes its >>>> hands: if we don't know how to do it properly, we better don't. >> >>> Leaving the problem open? I don't call it consistent. >> >> Incomplete, but consistent. Absence of solution is better than a wrong one. > > 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. > 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++. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de