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-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,ab66185f2bca0483 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-11-17 03:15:06 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!newsfeed.gamma.ru!Gamma.RU!fu-berlin.de!uni-berlin.de!dialin-145-254-038-135.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: Extension of non-limited type needs limited component Date: Sun, 17 Nov 2002 12:14:40 +0100 Organization: At home Message-ID: References: <2dbd76f3.0211130203.7d2d14fd@posting.google.com> <2dbd76f3.0211140126.5d233e41@posting.google.com> <3vb7tug4h99mmalcn0l5ul18cu0ui6i458@4ax.com> <6bd9tuc40p68a86rlur3hai1qlv54i8985@4ax.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-038-135.arcor-ip.net (145.254.38.135) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: fu-berlin.de 1037531703 16530883 145.254.38.135 (16 [77047]) User-Agent: KNode/0.7.1 Xref: archiver1.google.com comp.lang.ada:30995 Date: 2002-11-17T12:14:40+01:00 List-Id: Robert A Duff wrote: > "Dmitry A. Kazakov" writes: > >> All that are more or less decoupled things. Why should we tie all of them > ^^^^^^^^^^^^ >> under one roof? > > Less, I'd say. ;-) > > They are all closely related to whether you can copy the thing. Here we are. Why copying should be tied with: by-reference vs. not an ability to have uninitialized objects an ability to reference objects inheritance aggregation ... All this big variety of possibilities surely influence each other, but this does not mean that you can break all this into a simple: limited/non-limited. > To answer my question properly, you would have to explain exactly > when each of the things I mentioned should be allowed. I think that it would be better that the properties of an abstract type could be specified more directly. Currently we a doing it indirectly and very roughly, because the language has its own set of type properties which are not well mapped to ADT, for the programmer's point of view. To require all objects to be initialized is a damn simple thing. But to achieve this, one should make it discriminated! And then, no arrays of the type! Why all this? It is because of a wrong idea to control the program semantics. To put it very extremely, if a programmer wants to use the character sequence ":=" for his type, let him do it. It is not the language responsibility to make this ":=" semantically correct. The only thing a good safe language should do is to make the programmer aware of the consequences. For instance, require overriding of the user-defined ":=", in case of inheritance. Clarify that ":=" in declarations is not an assignment, but a copy-constructor. That ":=" will never be imlicitly used by the compiler to copy the components of the type, so if ":=" is defined, then Adjust has to be overridden, etc. > That's not > easy. No, I don't expect anybody to do all that work for an informal > usenet discussion. ;-) (:-)) >>...[However, I am afraid, that to correctly deal with it one >> would need multiple dispatch anyway.] > > I like the idea of multi-dispatch, but all of the languages I've seen > that support it seem confusing and/or error-prone. There should be a consistent solution. Otherwise the whole idea of dispatch was wrong. [I do not exclude this possibility] > You need a rule that > makes it predictable which method(s) will be called in every case. Not > just predictable in a formal sense, but predictable by mere mortal > programmers -- i.e. the programmer's guess should match what the > compiler actually does. The major problem I see is a geometric exposion of the methods to be overriden. In the case of binary operations it is three methods. If one gets overridden then all others shall be too. > And you need a way to prevent ambiguities -- > cases where two different methods are "reasonable" should be forbidden, > preferably at compile time. This could be done by a requirement of explicit overriding in all cases of potential ambiguities, but the consequence is the geometric explosion. > And you need a way to organize the code -- > with single dispatch, you can put the "methods" with the "type" (or > "class" or whatever). Yes, the freezing rules. There is practically no other solution than Ada's one: all methods to be declared before the first use. However it is not so restrictive as it might look. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de