🚀 go-pugleaf

According to craig@gpu.utcs.utoronto.ca (Craig Hubley):
>In article <27C2D4B8.3AD3@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
>Sometimes you must/can be aware of the [compile-time/run-time] seam.

In fact, I find it vital to keep ``the seam'' clearly in mind at all
times.  Perhaps some find this distinction irritating, and wish to
forget it.  I don't.

>You can remove the distinction [between compile-time and run-time binding]
>in many cases without removing the control.  Take overloading:  if I provide
>a function that accepts both Date("Feb.25/91") and Date(91, 2, 25) ...

I confess that the point of the Date() example escapes me.  It
describes only compile-time binding (of constructors, I assume, though
it hardly matters) and seems irrelevant to virtual functions.

>[initializations can be optimized away, if they only use...]
>static arguments that have no (derived types AND virtual functions)"

Of course.  But constant expression folding was state-of-the-art in
the 60's, and it has zero relevance to OOP typing issues.

>The choice of calling the "real" (Type *x; x->member; Type &y; y.member)
>or "formal" (Type x; x.member) (type-associated) function still belongs
>to the consuming programmer.

And the consuming programmer can always say "d.Base::member()", too,
overriding both static and dynamic typing.  But I confess that I the
relevance of this language feature to a supposed conflict between
overloading and virtual functions escapes me.

>>>When you mix virtuals and overloading, things get scary ...
>>"Well, don't do that, then."
>Then C++ is a far less powerful language.

I fail to see the weakness implied by this statement.

>>I would contend that, once virtual functions have been introduced into
>>a class hierarchy, the additional use of overloaded functions is the
>>design error to be corrected, not some presumed deficiency in C++.
>
>So you are saying *never* to overload virtuals ?  If so, then that is the
>strongest admission I can think of, that the present rules for doing so
>are useless.

No, no more than I would say *never* to use a goto.  What I *am*
saying is that the use of an overloaded virtual function likely points
out an opportunity to make a class design more regular.

In the absence of other considerations, I would suggest that the
overloading of the virtual function be subsumed into an overloaded
constructor (or non-member function), and that the constructed object
(or function return value) be used as an actual parameter of the
no-longer-overloaded virtual function.

The advantage of this change is that the expansion of the overloaded
alternatives requires only one change: an additional constructor or
non-member function.  An overloaded virtual function, to support an
equivalent expansion, would require N additional functions for the N
classes that implement the given virtual function.

>>The differences between these techniques is a tool, not a flaw.
>It is a flaw, not a tool.

We must agree to disagree, then.
-- 
Chip Salzenberg at Teltronics/TCT      <chip@tct.uucp>, <uunet!pdn!tct!chip>
"It's not a security hole, it's a SECURITY ABYSS." -- Christoph Splittgerber
   (with reference to the upage bug in Interactive UNIX and Everex ESIX)