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!r29g2000hsg.googlegroups.com!not-for-mail From: Maciej Sobczak Newsgroups: comp.lang.ada Subject: Re: Inherited Methods and such Date: Thu, 27 Sep 2007 14:02:37 -0700 Organization: http://groups.google.com Message-ID: <1190926957.815414.26640@r29g2000hsg.googlegroups.com> References: <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> <1190842261.235691.298520@50g2000hsm.googlegroups.com> NNTP-Posting-Host: 85.3.107.199 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1190926958 26795 127.0.0.1 (27 Sep 2007 21:02:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Thu, 27 Sep 2007 21:02:38 +0000 (UTC) In-Reply-To: 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: r29g2000hsg.googlegroups.com; posting-host=85.3.107.199; posting-account=ps2QrAMAAAA6_jCuRt2JEIpn5Otqf_w0 Xref: g2news2.google.com comp.lang.ada:2168 Date: 2007-09-27T14:02:37-07:00 List-Id: On 27 Wrz, 17:02, "Dmitry A. Kazakov" wrote: > > I can recover T'Class from T, as in the example from > > previous post. > > Nonetheless, T'Class /= T. Formally, you don't recover it, you create a new > object, then you call some operation on the result, and after completion > you convert it back. No. I can have an access variable to the object and I can observe modifications using this additional alias. This means that no new object is created. > The compiler may optimize memory use. For by-reference > type it could be required to do so. If it's required to optimize, then it's not optimization, but semantics. There is no new object. > > How is it possible to recover T'Class from T? > > Because T inherits class-wide operations of T'Class. Too bad. T'Class can be {T, S} or {T, S, U}, or ... and there is observable difference between them, so that redispatching on T might give different behaviours, which means that T /= T. Oops. > It has a primitive operation that constructs T'Class from T. For a > tagged type this operation uses the tag embedded in the representation of > T. Then you admit that there is something more than just T - the object is involved. You have just decoupled T from object. Still without views? :-) > In my view to avoid inconsistencies, the conversion T -> T'Class should > yield an object with the tag = T, no matter what the object was before, > otherwise it shall fail. I don't understand it. What is "otherwise"? There is no condition before that part. > Note an important difference to C++, C++ does this only upon > construction/destruction. I think that this should be done always. I think > we have discussed it before. I'll try to explain it on a different model: > > Consider a specific type as a point T. > Then a class were an open interval [T, oo[. > > The types algebra is built on points and open intervals. Subprograms are > defined on either points or intervals. So far, so good. > > Now, what you want is to get in the constructor of some S derived from T, > something like a *closed* interval: [T, S]. > > But you don't have operations in the types algebra for dealing with such > beasts. And the subroutines aren't defined on them. This is inconsistent > with the setup above. Additionally to specific, polymorphic operations it > would require "finite" operations. They should be allowed outside the > constructors, i.e. they would leak out in the language for the sake of > regularity. It will be complex. Yes, but this assumes that these types would be needed outside of constructors. I mean - outside of the temporal frame when this actually matters. C++ avoids this complexity by limiting the time frame when this phenomenon occurs and uses open intervals during the "regular" lifetime of the object. Is it inconsistent? Yes, if the static type algebra is requested - that's your point as I understand. Does it work "properly" when expected? Yes, for some reasonable definition of "properly". > > But you claimed that views are not needed. Try to explain this without > > reinventing views. :-) > > See above. T /= T Recovering T'Class from T is not in T's interface. It's the object that does it. There is some necessary magic in redispatch that bypasses T and get's to the object directly (inconsistency), but T itself does not have this operation. > > None of Initializes was called before T'Class was complete. That's the > > problem. It's entirely reversed, leading to untyped mess. > > *If* Initialize were a constructor. Exactly. The point is that without constructors we have to resort the the next closest match. Even if that leads to mess. > > I want to set up a framework for the abstract factory design pattern. > Register from the constructor of T'Class. I don't want to, because that exposes the registry to the developers of T'Class and it was supposed to be encapsulated part of the framework. Last but not least - what if the developer of T'Class forgets to register? How can I force it? Registering from the base type is more straightforward - and safer. > > A client can ask for the additional interface after discovering the > > concrete type. > > It is called dispatching, no need in changing type. Dispatching does that > for you. No, it does not give the *additional* interface. -- Maciej Sobczak http://www.msobczak.com/