* Something like "->" in Ada?
@ 1996-04-01 0:00 Chris O'Regan
1996-04-01 0:00 ` Robert Dewar
0 siblings, 1 reply; 7+ messages in thread
From: Chris O'Regan @ 1996-04-01 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-01 0:00 Something like "->" in Ada? Chris O'Regan
@ 1996-04-01 0:00 ` Robert Dewar
1996-04-02 0:00 ` Mike Young
0 siblings, 1 reply; 7+ messages in thread
From: Robert Dewar @ 1996-04-01 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-01 0:00 ` Robert Dewar
@ 1996-04-02 0:00 ` Mike Young
1996-04-03 0:00 ` Robert Dewar
1996-04-03 0:00 ` Tucker Taft
0 siblings, 2 replies; 7+ messages in thread
From: Mike Young @ 1996-04-02 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-02 0:00 ` Mike Young
1996-04-03 0:00 ` Robert Dewar
@ 1996-04-03 0:00 ` Tucker Taft
1 sibling, 0 replies; 7+ messages in thread
From: Tucker Taft @ 1996-04-03 0:00 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-02 0:00 ` Mike Young
@ 1996-04-03 0:00 ` Robert Dewar
1996-04-04 0:00 ` Mike Young
1996-04-04 0:00 ` Mike Young
1996-04-03 0:00 ` Tucker Taft
1 sibling, 2 replies; 7+ messages in thread
From: Robert Dewar @ 1996-04-03 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-03 0:00 ` Robert Dewar
1996-04-04 0:00 ` Mike Young
@ 1996-04-04 0:00 ` Mike Young
1 sibling, 0 replies; 7+ messages in thread
From: Mike Young @ 1996-04-04 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Something like "->" in Ada?
1996-04-03 0:00 ` Robert Dewar
@ 1996-04-04 0:00 ` Mike Young
1996-04-04 0:00 ` Mike Young
1 sibling, 0 replies; 7+ messages in thread
From: Mike Young @ 1996-04-04 0:00 UTC (permalink / raw)
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1996-04-04 0:00 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-04-01 0:00 Something like "->" in Ada? Chris O'Regan
1996-04-01 0:00 ` Robert Dewar
1996-04-02 0:00 ` Mike Young
1996-04-03 0:00 ` Robert Dewar
1996-04-04 0:00 ` Mike Young
1996-04-04 0:00 ` Mike Young
1996-04-03 0:00 ` Tucker Taft
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox