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=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c9a5d6b3975624e1 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2002-10-04 17:20:43 PST Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!wn11feed!worldnet.att.net!bgtnsc05-news.ops.worldnet.att.net.POSTED!not-for-mail Message-ID: <3D9E3018.8000403@worldnet.att.net> From: Jim Rogers User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: OO in Ada References: <3D9D02F3.9090600@worldnet.att.net> <1033752899.224298@master.nyc.kbcfp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 05 Oct 2002 00:20:43 GMT NNTP-Posting-Host: 12.86.35.173 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc05-news.ops.worldnet.att.net 1033777243 12.86.35.173 (Sat, 05 Oct 2002 00:20:43 GMT) NNTP-Posting-Date: Sat, 05 Oct 2002 00:20:43 GMT Organization: AT&T Worldnet Xref: archiver1.google.com comp.lang.ada:29527 Date: 2002-10-05T00:20:43+00:00 List-Id: Hyman Rosen wrote: > Jim Rogers wrote: > > In C++ this syntax is good for virtual functions > > but illegal for static functions. This causes nasty > > problems in C++ template construction. > > You don't mean 'virtual' and 'static', you mean > 'member function' and 'non-member function'. It's > not so much an issue of nasty problems. It's just > that having two different notations for calling a > method means that when you're writing a template > you have to know which notation to use, which > limits its genericity. Thank you. That is just what I wanted to say if I knew C++ better. Sorry about the error. > > > C++ (and Java) forbid dispatching based upon the > > return type of a function. This is one of the > >> side effects of the 'object.method' notation. > > > Your first statement is true, but your second is > false. Why do you think object.method would prevent > dispatching on return type? > I think that because the dispatching is always performed on the type of "object" in object.method. This rule would have to be seriously modified to dispatch on the return type of a function (or method in Java's terminology). >> should be phased out by allowing [member] functions > > > to be called in the same way as [non-member] functions. > > It will never be phased out, of course, since that would > destroy millions of lines of code. Someone might come up > with a reasonable proposal for allowing the method(object) > notation, though. The problem is the impact this owuld have > on overloading and name lookup, which is already extremely > complicated. > > The design issue for C++ is that sometimes you want member > functions as part of an interface and sometimes you want > standalone functions. Having a different calling notation > makes it harder to switch the function from one type to the > other, because you have to modify all the callers. > > On the other hand, Ada gives the illusion of multiple dispatch > by allowing several parameters to control dispatching, but then > forcing them all, at runtime, to have the same dynamic type. I > suppose some future version of Ada could lift this restriction > while keeping the same notation, which is good. > > I disagree here. Ada does not give the illusion of multiple dispatch. An Ada subprogram can only be primitive to one type. That characteristic is determined by the place in the source code where the subprogram interface is defined. I am not really happy with this design feature, but it is what it is. Jim Rogers