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!19g2000hsx.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Mon, 24 Sep 2007 08:02:05 -0700 Organization: http://groups.google.com Message-ID: <1190646125.024072.310020@19g2000hsx.googlegroups.com> References: <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> <1190497995.498679.119190@19g2000hsx.googlegroups.com> <1mw3qju08q8uj.sgzht7ld9ydc$.dlg@40tude.net> <1190579805.451187.71140@d55g2000hsg.googlegroups.com> <1i8ksr774bjbj.vpmnx3c0i9qz.dlg@40tude.net> NNTP-Posting-Host: 137.138.37.241 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190646125 4790 127.0.0.1 (24 Sep 2007 15:02:05 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 24 Sep 2007 15:02:05 +0000 (UTC) In-Reply-To: <1i8ksr774bjbj.vpmnx3c0i9qz.dlg@40tude.net> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.12) Gecko/20070724 Red Hat/1.5.0.12-0.3.slc3 Firefox/1.5.0.12,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: 19g2000hsx.googlegroups.com; posting-host=137.138.37.241; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2114 Date: 2007-09-24T08:02:05-07:00 List-Id: On 24 Wrz, 11:32, "Dmitry A. Kazakov" wrote: > > T'Class. It has no meaning, because there is no possible family of > > types there. There is one type T and everything dispatches to T. > > Forget dynamic dispatch where you are in the constructor. > > Sorry, are you arguing against the concept or against C++ model (that uses > this concept in an inappropriate way? (:-)) I'm arguing against using this concept in the context of constructor. It does not belong there for the simple reason - T'Class denotes a potential family of specific types. These don't exist yet. > > The funny part is that formally there is no such object yet. > > Finally. And how is it called when something non-existing can still be used > as if it were existing and, moreover, were of the type T? It is called > "untyped mess." And how is it called when something dispatches into vacuum? I think "untyped mess" is not exact. Close, but not exact. :-) > > Still, there is a lot I can do from the methods of the class, > > which understand the state. These methods can even operate before the > > invariants of T are fully established. After all, it's their natural > > ability. > > No, this is incorrect. Methods are allowed to break public invariants in > the course of their execution. But that by no means implies that invariants > do not hold on the method's input and output. It's up to the designer to decide which methods can be called and which invariants should hold and where. > My position > is even stricter. It is that it is inconsistent to dispatch even after > having a fully constructed T. To dispatch you have to construct a > polymorphic object (like T'Class), to have a specific T is only a premise > of construction of T'Class. OK. Let's forbid to call virtual functions altogether until the full object is ready. I'm fine with such restriction. > Note the implication: if you construct an S derived from T and have > constructed only T, then T'Class is still not constructed and you cannot > dispatch. Only after construction of S, you can proceed to T'Class, and > after that, lo and behold, you can dispatch safely! This is extreme, but I understand it. The C++ way is to allow dispatch with just T, by restricting the dispatch itself to T only (this is more meaningful when more types are involved in the chain, so that you can already talk about T'Class after constructing T *and* S, but not yet U, V and W - this is already polymorphic in the restricted T+S sense). > This is why I am arguing for class-wide constructors (strictly speaking, > user-defined hooks on the completion of). From there you could dispatch. OK. Such a restriction makes sense when seen in isolation, but makes some scenarios rather clunky, see below. > > What are we discussing, then? :-) > > That the type of a given object is invariant. 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. One possibility would be to register kind of proxy instead and that proxy could be used to query whether the object is ready or not. But this is not really different from having a built-in dispatch that changes the depth of dispatch dynamically, so we're back at the same problem. > > How do you compare C++ with Ada in this context? > > In Ada it is called T'Class. I'm asking about the "aberration" part. > > I understand your objection that in this case (given the above > > constraint) it's not T anymore, but making it formally complete would > > bring more practical issues than it theoretically solves. > > That is another discussion. The point was about inconsistency of the model. Yes, it has holes. I still prefer it due to the fact that it does not dispatch into vacuum. > Ada does not have user-defined constructors, so it stays consistent. Yes. > Though > this greatly limits Ada and gives the birth to chimerical constructs like > functions returning limited objects. This is just part of the problem. Another part is dispatch into vacuum. > Formally it would mean that the object is of the type > > class {T1,T2,...,Tn} > > where T1-Tn is the construction path. This type has the operation > "address," etc. Alas, this is not what actually happens. Because, as you > claimed, you can dispatch and the target of dispatch moves => it is more > than just one class. It is not even a type, it is a set of. Something like > > { class {T1}, class {T1, T2}, class {T1, T2, T3}, ... } Yes. Keep in mind the temporal aspect of this. > But the effect of all this horrible mess is equivalent to the following > simpler set of types: > > { T1, T2, T3, ... } No. You lost the temporal aspect. :-) > This is why I initially said that > > 1. it does not dispatch (in the simpler model); > 2. the type is specific in each "constructor"; > 3. the thingy is untyped because we have a set of types instead one Surely you lost the temporal aspect. The thingy is typed, because at any given moment the target of the dispatch can be predicted. > > What about growing up? > > The attributes do. No. Children and Adults have different interfaces. It's not even the case-block-pretending-dispatch. There are different primitive operations, some of them not even rooted in Human. > If you want to keep it one class (human), you are forced > to have a model where each client would be able to deal with either a child > or an adult. No. I can add new operations in derived types. > > View is what you have with references to objects. There is nothing to > > introduce here. > > You did references. Is reference an object? What is the type of? Reference is not an object. It it only a "telephone conversation" with some object. Whether references need to have types at all is a matter of taste. They can be transparent (untyped), but in typed language they should be typed and their type can be T'Class (or just T if the language allows it - this influences how the dispatch works). > 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. In the extreme case (see Java) references are the only way to talk to objects, so no new type is needed, because there is no way to confuse the type of the object with the type of the reference. > > And your point is? Mine was that dynamic_cast does not give another > > object. > > It does. Any function returns a new object. Simple? (:-)) If you define it like this, yes. But I can extend the notion of the function so that function can return views, which are not object. Simple. :-) Control question: what is the identity of the view? :-) > > If I dispatch to the type where even the fields were > > not yet initialized, how I can decide what I can do? Which type should > > I ask? > > q.e.d. > > You cannot consistently answer this question => the model is wrong. C++ avoids this question by not dispatching into vacuum. If there is no question, then there is no problem with the answer or the lack of it. > 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. > >> ---------------- > >> Just annotate types. Fields construction does struct {...}. No less, no > >> more. [...] > > I like it. Really. > > Well, not really. Indeed - I cannot register from constructor. Registering a proxy leaves me again with some form of dynamic_cast changing its behavior with time, but just with different name. -- Maciej Sobczak http://www.msobczak.com/