Re: Parameter Modes, In In Out and Out

[Brian Rogoff <bpr@shell5.ba.best.com>]

On Sun, 14 Jan 2001, Robert Dewar wrote:
> In article
> <Pine.BSF.4.21.0101141234130.2654-100000@shell5.ba.best.com>,
>   Brian Rogoff <bpr@shell5.ba.best.com> wrote:
> > I'm still wondering if anyone (Dmitry?) can come up with some
> > good  (natural, commonly occurring, etc.) examples which use
> > triple or  n-tuple dispatch where n > 2. All of the examples
> > I've run into so far are double-dispatch.
> 
> Right, indeed examples would be interesting. I have been trying
> to provoke Dmitry to come up with examples, but so far without
> success :-)

I was actually of a similar disposition as Dmitry a few years ago w.r.t 
MD, but as I studied the issue more and looked at my own code in Ada and 
similar languages I managed to convince myself that it wouldn't be worth
it in Ada. Any CLOS programmers out there with different opinions? I never 
used Common Lisp enough to have it "at my fingertips" so maybe there are 
things I've missed.

I have bigger fish to fry now too. Why worry about MD when there are quite
a few aspects of protected types that need fixing? IMO, a good way to
judge if something qualifies as a potential Ada enhancement is if you have 
an actual coding experience with Ada where a (missing) feature caused pain
and the workaround was insufficient. For instance, the Rosen trick has 
lessened my pain at the lack of out params in functions so that even
though it seems naughty I won't complain about this flaw again. 

> > Well, surely you read the note about the ESA project which
> > eschewed  Ada in favor of C++ on account of the inability to
> > do Java style  MI of interface in Ada? That may not count as
> > customer demand, but  it is an interesting data point
> > nonetheless.
> 
> Well it certainly does not count as customer demand :-) As far
> as I know the ESA did not even investigate the possibility of
> whether this feature could be added to Ada (if they consider
> Java as potentially usable, then obviously language standards
> are not a consideration :-)

OK wiseguy, joke noted. They actually went with C++, and there library 
relies on conventions to restrict MI use to Java style, with pure abstract 
virtual base classes representing interfaces. 

> But more to the point, when you here someone say
> 
> I am choosing language X instead of Ada because Ada does not
> have Y.
> 
> Then it does not mean that if Ada *did* have Y, they would
> have chosen Ada.

Understood. Ada has lots of stuff C++ doesn't have. The lack of nested 
subprograms (with lexical scope) in a language is real turn-off, IMO. 

> I agree it is worth pursuing, but if the ESA is saying that
> the only way they can make their birds fly is to use Java
> style MI, then that's not very convincing!

No, I think their argument is more along the lines of "We found this 
style of OO to enhance reusability and maintainability", and expressing it
in Ada (with the self referential access discriminant trick) is a clumsy. 
For pure interface style programming, I see their point. Access discriminants 
provide a decent way to do MI of implementation (IMO) but Java style
interfaces do seem to hit a nice "sweet spot" of safe MI usage and
providing direct syntactic support for this in the language is worth
looking at. 

You're probably right that a preprocessor which deals with the clunky 
access discriminant stuff is a better fast track to a prototype than 
modifying GNAT. 

-- Brian