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,760a0492b97ae06e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-22 01:59:42 PST Path: archiver1.google.com!news2.google.com!fu-berlin.de!uni-berlin.de!dialin-145-254-042-178.arcor-ip.NET!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: How to test object hierarchy Date: Mon, 22 Dec 2003 11:05:56 +0100 Organization: At home Message-ID: References: <93172edb.0312181024.9a536b2@posting.google.com> <49cbf610.0312211158.87338af@posting.google.com> Reply-To: mailbox@dmitry-kazakov.de NNTP-Posting-Host: dialin-145-254-042-178.arcor-ip.net (145.254.42.178) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Trace: news.uni-berlin.de 1072087181 10020845 145.254.42.178 ([77047]) User-Agent: KNode/0.7.2 Xref: archiver1.google.com comp.lang.ada:3691 Date: 2003-12-22T11:05:56+01:00 List-Id: Dmytry Lavrov wrote: > "Dmitry A. Kazakov" wrote in message > news:... >> >> I think that IF Ada should have multiple dispatch on different types > > Wao.That's exactly(multiple dispatch) that i tried to explain to > peoples(very experienced and probably smart too ) who know only > "object.method" notation. > Of course that failed(they even can't understand what it is it), > because that damn "."(like fields in record) left place only for one > object! > > i got probably good(and also wild) idea that > method(paramether,paramether,...) are shugar for > method(composed_class_constructor(paramether1,paramether2,...) ) > > and if thete's multiple inheritance, it's > method(temporary_child_class_constructor(parent1,parent2,...) ); > > and also about that it's shugar for > dispatch(in paramether1[, in paramether2....]).method(in out > paramether1[,in out paramether2....]); > - it can be implemented without changing the language at all,but need > lots of stupid work with "procedural variables". > > Maybe that could give someone here any good idea. > > (it was about problem with overloading math operators for classes- > double dispathing was required - different methods for matrix by > matrix,matrix by scalar,matrix by vector,vector by matrix,etc,in all > combinations including complex number stuff ,etc. ) The case you are describing is multiple dispatch on same type. It is a bit easier, especially because the existing freezing rules are OK and because it still allows C++ appoach of having virtual table pointer buried in objects. I have posted an example how to deal with it. You can also take a look at http://www.dmitry-kazakov.de/ada/components.htm where it is used for "=", "<" operations. But the pet idea of many OOPLs that methods belong to object is absolutely wrong. So the prefix notation. The pressure is so high that there is an AI to introduce it in Ada! (It already exists for tasks and protected objects) >> then >> inevitably we should reconsider the freezing rules. The most useful >> implementations of MD appear when types are defined in different >> packages. The rationale behind the existing freezing rules is to prevent >> dispatching to non-elaborated targets. I believe that for a MD operation >> the freezing point could be the last freezing point of all involved >> types. For example: >> >> package Devices is >> type Device is tagged ...; >> procedure Load (X : in out Device); >> end Device; -- No more primitive operations with only Device >> >> with Devices; use Devices; >> package Curves is >> type Curve is tagged ...; >> procedure Show (X : in out Device; Y : Curve); >> end Curves; -- No more operations with Device and Curve >> >> It is clear that these rules can be very dangerous, if we will not limit >> use of non-primitive operations (except the class-wide ones). The first >> step could be to make all types "tagged". But even this could be not >> enough. > > Main problem that compiler will no longer detect some errors,right? Errors, undesired overloadings, where overriding was meant, backward compatibility all that things. -- Regards, Dmitry A. Kazakov www.dmitry-kazakov.de