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: Sat, 22 Sep 2007 14:53:15 -0700 Organization: http://groups.google.com Message-ID: <1190497995.498679.119190@19g2000hsx.googlegroups.com> References: <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> NNTP-Posting-Host: 85.3.64.98 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190497995 31126 127.0.0.1 (22 Sep 2007 21:53:15 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sat, 22 Sep 2007 21:53:15 +0000 (UTC) In-Reply-To: <9ukf2wtqjs0q$.iuijmal4x56b$.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: 19g2000hsx.googlegroups.com; posting-host=85.3.64.98; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2091 Date: 2007-09-22T14:53:15-07:00 List-Id: On 22 Wrz, 10:48, "Dmitry A. Kazakov" wrote: > > OK. But then your initial usage of it (still cited above) is wrong in > > case of constructor, because the type changes in the "more specific" > > direction. > > It is not "more specific." Just note the name, it is called programming "by > extension" This name does not matter much to me. Something can be more specific and require additional state to provide this more specific behavior. > >> class T > >> { > >> T () { f(); g(); } > >> void g() {} > >> virtual void f() {} > > >> }; > > Not exactly. In the constructor of T, *this already has type T. > > But you objected that *this is specific. You claimed that it dispatches in > f(), if it does then it is of T'Class. This concept has no meaning there. *this is of type T and dispatches to T::_(). > When you claim that T has been constructed prior the body of T(), then the > latter simply cannot be a constructor of T! It is a constructor, because the initializer list is part of T::T(). To be strict, object is considered to be constructed *after* the constructor executes to the end (without an exception), so formally the object is not yet constructed when T::T() is executing its body. The point is that in the constructor's body the components (fields) are already constructed (the initializer list handles this) and this fact makes it safe to use these fields. This is important - you can *use* the fields, because they were already constructed. It would not be possible if *this dispatched to Derived::f(), because there the Derived's fields do not yet exist. > It is plainly inconsistent. It is consistent - the dispatch will never trick you into using not- yet-constructed fields. > If it were T'Class then f() would function properly as it shall do on the > class. But it does not. It exposes a different behavior, hence, either it > has a different type, or else the language is wrong. You got stuck with the idea that T'Class must be constant. > The point is that in NO typed language a constructor can be > defined solely in the language terms. Constructors have to be generated > "per magic." But the language shall provide hooks for user-defined > insertions in the generated constructors at the points, where the type > contracts are satisfied. Isn't it obvious? Makes sense. Isn't it true in what I describe? > Ada keeps on trying to use only magic. Returning limited types, new in Ada > 2005, is just another step in this direction. This is IMO a road to > nowhere. And also, it is inconsistent with Ada's own stance on types > matching by-name rather than by-structure. Surprisingly, but C++ took the > opposite direction, alas its construction model is inconsistent. I don't see any inconsistency there. The inconsistency can be found under the assumption that types must be invariant. But if we remove this assumption, then the inconsistency is gone. > > Constructor is not a function - you cannot just "call" > > it. > > You mean that ptr->T::T() is illegal in the current incarnation of C++? Exactly. > Don't hurry, I can pass this as parameter: > > T() : A(this), B(this), C(this) {...} > > and enjoy all the mess. Yes. You can remove this by prohibiting the use of 'this' in the initializer list (some compilers warn about it anyway). It is formally allowed, because can be useful if handled with enough care. Kind of Unrestricted_Access. > > Identifier is permanent and this allows me to say that the object > > *persists* along the process (there is no object replacement, etc.). > > The type evolves during this process. > > What does persist? What is an object? You said it has a name. I am excited, > but it does not help me in any way. What can I do with the object through > its wonderful name? If you say that I can take its address, then that > means: the type (behavior) has the function &. If you say that I cannot > take its address, then the type does not have &. Either or. You cannot have > conditionally legal methods in a statically typed language. I don't get it. You can call & on the type, unless operator& is private. How does it relate to the rest of the discussion, anyway? > > What about growing up? > > The type is Human. Height is an attribute of. I'm not talking about getting higher, but about growing up. Human has subclasses Child and Adult. Presumably they can do different things. :-) So - what about growing up? The only way to grow up the child in Ada and C++ is to kill a child and resurrect it as an adult, reshuffling all necessary references in the system so that they point to the new entity. Not funny. > > What about getting promoted in the company? > > The type is Employee. Rank is an attribute of. Too easy. Employees on different levels on their career paths have different attributes as well. For example, Managers have lists of people who report to them. Employees with different contracts have different attributes related to how their salary is computed. Etc. Same problem as growing up. > Actual type /= the type. The type = a common denominator of the behavior of > "all objects like this." When you say that the behavior changes in a way > the you cannot identify anything common, then it is "strongly" untyped [and > absolutely useless too]. If you say that you can determine something like > "actual" type, then it is "weakly untyped." Any such system can be made > "strongly typed," by introducing methods like . Here > is defined on the true type. "Actual type" is just the type > of the result of the method and it yields *another* object. > In cannot be the same object, because the types differs. If they differ > then equivalently there exists a method you can apply to one, but not to > another. For this method you cannot say if it were legal to apply it to the > object that has both types. No. dynamic_cast gives another view on the same object. It does not give another object. You talk with someone over the phone. At some point you discover that it's an adult, then you agree with him (dynamic_cast) that from now on you can talk like adults. It's still the same person, you just know more about him. > > Because the language recognizes the fact that construction/destruction > > does not happen immediately and it is a "build-up" process. Assignment > > is performed on the object that is already "established". > > You introduce many new terms: "immediately," "built-in," "established." > Why these should be relevant to a type system? Do we need such complexity? As long as things don't happen "immediately", yes. Without this "complexity" you get real complexity with dispatching to vacuum. > And what does prevent you from accepting the proposition that no object > exists prior its construction? Why do you thing it would conflict with anything here? If you think that it would prevent me from doing anything in the constructor (because I cannot do anything if there is no object), then it's wrong - in the constructor I can use already constructed fields. Even from other functions, which are called by the constructor. It's after the constructor finishes when the clients can use the object via its public interface. From their point of view the object exists after the constructor finished. From the constructor point of view, the fields exist before the constructor's body is executed. Easy. -- Maciej Sobczak http://www.msobczak.com/