Something like "->" in Ada?

Something like "->" in Ada?

[Chris O'Regan]

Hello,

   I am learning OOP with Ada 95.  Although I have only a bit of experience,
mostly with Perl 5, I find that the "->" operator is much more intuitive
than passing an object as a parameter to a subprogram.  Is it possible to
define "->" as the following:

	method( object ) = object->method()


   If so, how would I do that?


Thanks in advance,
--
    ____________________________________________________________________
     Chris O'Regan <chris@ECE.Concordia.CA>, UNIX Systems Administrator
              Department of Electrical and Computer Engineering
                   Concordia University, Montreal, Canada
                http://www.ECE.Concordia.CA/~chris/addr.html

Re: Something like "->" in Ada?

[Robert Dewar]

Chris says

"   I am learning OOP with Ada 95.  Although I have only a bit of experience,
mostly with Perl 5, I find that the "->" operator is much more intuitive
than passing an object as a parameter to a subprogram.  Is it possible to
define "->" as the following:"

What you are used to always seems more intuitive than what you are
getting used to. Wait till you can say "I have completely learned OOP
with Ada 95", then see what you think. Many people think that the
procdure argument approach is in fact much simpler, and that the ->
is unnecssarily restrictive and over-specific.

Re: Something like "->" in Ada?

[Mike Young]

Robert Dewar wrote:
> 
> Chris says
> 
> "   I am learning OOP with Ada 95.  Although I have only a bit of experience,
> mostly with Perl 5, I find that the "->" operator is much more intuitive
> than passing an object as a parameter to a subprogram.  Is it possible to
> define "->" as the following:"
> 
> What you are used to always seems more intuitive than what you are
> getting used to. Wait till you can say "I have completely learned OOP
> with Ada 95", then see what you think. Many people think that the
> procdure argument approach is in fact much simpler, and that the ->
> is unnecssarily restrictive and over-specific.

=======
Mayhaps, Robert. I would appreciate any help you might offer.

In playing with Intermetric's adajava package last night, I had 
an interesting few minutes translating the following Java statement into 
Ada-ish code:

   (size().width - g.getFontMetrics().stringWidth(helloStr))

The Ada equivalents I finally coughed up are:

1) (size(this).width - stringWidth(getFontMetrics(G), hello_Str))

2) declare
     pSize : Rectangle_Ptr := size(this);
     fontM : FontMetrics_Ptr := getFontMetrics(G);
   begin
     ...
       (pSize.width - stringWidth(fontM, hello_Str)),
       ...
   end;

In other words:          g().f().func(...);
compares to:             func(f(g(this)), ...);

I'm not drawing any conclusions from this exercise, but the contrast 
between Java's cascading style and Ada's func(f(g(x)), ...) style 
appears somewhat extreme. The Java version is consistent with a 
heirarchy (g.getFontMetrics().stringWidth(...)); this has some value 
when trying to unravel what stringWidth is. Also, there's a certain 
inconsistency in inverting the relationship when an attribute is 
directly accessed, compared to calling functions only. Changing an 
attribute into a function call would involve more work in re-ordering 
the statement.

But, as you say, it's probably a matter of acclimation. 

Mike.

Re: Something like "->" in Ada?

[Robert Dewar]

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.

Re: Something like "->" in Ada?

[Mike Young]

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 talk of 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. 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.

Re: Something like "->" in Ada?

[Mike Young]

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.

Re: Something like "->" in Ada?

[Tucker Taft]

Mike Young (mikey@mcs.com) wrote:

: ...
: In playing with Intermetric's adajava package last night, I had 
: an interesting few minutes translating the following Java statement into 
: Ada-ish code:

:    (size().width - g.getFontMetrics().stringWidth(helloStr))

: The Ada equivalents I finally coughed up are:

: 1) (size(this).width - stringWidth(getFontMetrics(G), hello_Str))
: ...

Of course, given my background, I find this latter form much 
easier to grok.  Perhaps something like the following is
going on (speculating on how my perception works here; add
big grain of salt... ;-):

   with the prefix form g.f(a).h(b,c), the name of the thing you 
   are getting ("h") is buried in the middle of the expression, 
   whereas with the "params inside" form, the function name comes 
   at the front, so you know right away that you are getting a 
   stringWidth.  With field selection the name at least comes at 
   the very end, rather than buried in the middle.

It is interesting that Java code examples often have very short
variable names.  If your variable names are relative long, such
as:
    currentGraphicsObj.getFontMetrics().stringWidth(stringOfInterest)

then it becomes even harder to find the important signal with all the noise.

As another example, in using Java, one of the "perceptually" confusing 
lines I see frequently is:

    System.out.println(Message);

whereas in Ada/Java this becomes (presuming "use" clauses):

    println(stdout, Message);

Again, I find the Ada usage much easier to understand at first glance, 
given my background.  The complete conceptual switches between 
"System" (a class), "out" (an object), and "println" (a method) in 
the Java version is particularly unhelpful to my perception.

I suppose in Ada, I think of "." as meaning "digging into" the
guts of an object or package, and I think of "()" as performing
some operation.  When "." means both digging in and invoking
a method, depending on context, I find it harder to intuit the
meaning on a first reading.

I suspect it is somewhat the reverse-polish
vs. infix issue again.  One is easier to write, the other is
(at least for some folks!) easier to read.  Since on a calculator,
noone is generally reading the result of your button pushes, a 
reverse-polish approach makes good sense.  In a programming language,
you can argue for the most readable -- which is unfortunately
going to vary depending on your background.

: But, as you say, it's probably a matter of acclimation. 

For sure.  Vive la difference.

: Mike.

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA