Re: RFC: New C++ Attribute: final

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Joe Buck <Joe.Buck@synopsys.com> writes:

| On Mon, Mar 01, 2004 at 07:46:55PM +0100, Gabriel Dos Reis wrote:
| > While not stating my opinion on that keyword, a frequent counter
| > argument (that I rather find persuasive) is that "final" when defended
| > as above is presented as a feature for "write-only codes with no proper
| > design".  
| 
| Every problem in computer science can be solved by an extra level of
| indirection.  Or rather, every problem other than inadequate performance.
| 
| Such claims usually come from those who follow rigid ideological
| approaches to object-oriented design.

More precisely, such claims often come from people with particular
views on what object-oriented design means.  That does not mean that
such claims always come from those people.  In particular such
arguments should be analyzed on their own basis, not based on the religion
of the persons one may think it comes from.

|  If I propose to have a general
| matrix class and then some derived matrix classes that are tuned to
| optimize particular operations, these overly rigid gurus will object if I
| want to mark any operations in the tuned subclasses as final, because the
| guru will be able to come up with some theoretical reason why someone will
| want to further subclass the tuned implementations and therefore insists
| that I destroy the performance (by making all the operations virtual).

I don't know of the gurus you have had to speak with, but the ones I
have had spoken and work with just don't use virtual functions for
matrices or any other classes that have value semantics.  Not that
they don't like what is fuzzily called "object oriented" programming
-- they actually have design in layers where the non-"computational"
part is presented to users through abstract classes.  They also use
multiple inheritance where appropriate to satisfy a given interface --
usually the inherited concrete Matrix is non-polymorphic and the
interface is implemented in terms of those "concrete" classes.
They don't invoke any theoretical arguments:  their classes where
value based and they saw no reason to say differently in their
implementations. 

I sympathize you weren't successful in convincing the gurus you had to
speak with, but I would not reject such claims just because you had
spoken to  gurus you could not convince.  But I doubt that arguments
that speak of rigid ideological approaches to obejct-oriented design
or such will turn people mind into suddendly accepting the keyword.
(Quiz: Who is ideological?  The people  insisting or the people
rejecting?)  C++98 has missed useful and important features partly
because some proponents have taken the approach of treating their
opponents as "ignorant", "rigid", or "middle class anglo-saxons".
Such characterizations just inflame the debate with bringing a
valuable benefit, at least as far as the proposed features are
concerned. (It is a case where one would prefer not to have such
proponents :-))

I hope anyone interested in defending that keyword before the C++
committee  would not fall into that trap again.

-- Gaby