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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,52d41ed2965dfc50
X-Google-Attributes: gid103376,public
From: Mike Young <mikey@mcs.com>
Subject: Re: Something like "->" in Ada?
Date: 1996/04/04
Message-ID: <3164A243.418D@mcs.com>#1/1
X-Deja-AN: 145897822
references: <4jpd79$ces@newsflash.concordia.ca> <dewar.828419317@schonberg>
 <31620B5E.FCD@mcs.com> <dewar.828580219@schonberg>
content-type: text/plain; charset=us-ascii
organization: Fen Software, Inc.
mime-version: 1.0
newsgroups: comp.lang.ada
x-mailer: Mozilla 2.01Gold (Win95; I)
Date: 1996-04-04T00:00:00+00:00
List-Id: <comp.lang.ada>

Robert Dewar wrote:
> 
> Mike said
> 
> "But, as you say, it's probably a matter of acclimation."
> 
> Probably. One thing you can say is that the Ada approach is more general.
> FOr instance if you declare an operation "+" in an abstract algebra, and
> then you derive a particular concrete algebra with a specific concrete
> "+" operator, this fits into the Ada scheme cleanly and easily, but in
> a "send mssage to this object" paradigm, it is awkward and forced, if
> cleanly possible at all.

===========
It seems the mention of "sending messages" sidetracked this to something 
like Smalltalk (?). This was not the intention. In either case, I miss 
your point.

It's not possible in C++ to override an infix operator (that is, they 
cannot be virtual... ummm, polymorphic). The "work-around" is to define 
a concrete infix operator in terms of a polymorphic private method:


class B {
public:
  B operator+(const B& b) const
  { return Add(b); }

private:
  virtual B Add(const B& b) const = 0; // pure virtual
};

Public concrete children of B will now dispatch to their own (or 
inherited) Add, unless some intervening class in the inheritance chain 
also hides (can't override) "+".

I don't recall how overriding infix operators fits in context with the 
original discussion regarding x.f() versus f(x). Also, as yet, nobody 
addressed the disparity between attributes and sub-programs in context 
of cascading (C++, Java) vs explicitly passing "this" to sub-programs 
(Ada). The following are (I hope) equivalent:

Java-ish:
  d = x.a().b().c;    // where c is an attribute of return from b().
  e = x.a().b().c();  // where c is a method of return from b().
  f = x.a().b.c();    // where b is an attribute of return from x.a()

Ada-ish:
  D := B(A(X)).C;
  E := C(B(A(X)));
  F := C(A(X).B);

In all Java-ish examples, the path from x to a to b to c is clear and 
consistent. I apparently have a great deal of re-acclimating to do 
before intuitively grasping the same in Ada-ish. I understand the 
algorithm: start from deepest paren level, look left, look right, repeat 
until we run outa parens. This feels very much like the much despised 
C-pointer-to-function "parsing" algorithm.

(I'm not nit-picking the languages to death. This follows-up on the 
original poster's question regarding preference for Perl's "->" notation 
versus Ada's function call notation.)

Mike.