* 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-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
* 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
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