RE: Eliminating a couple of independent face definitions

[Davis Herring]

> That comes back to my earlier suggestion of "inheriting" from constant
> (uncustomizable) "faces".

I don't see the point in having anything be uncustomizable, though -- just
give it a name `function-name-base' and perhaps a docstring that says
"customize only if you want a global effect; otherwise customize the
inheritors".  More on this idea below.

> A user might well want to customize A, but without having repercussions
> elsewhere.  S?he cannot do that, and that fact will affect whether s?he
> ultimately "wants" to customize A.  After becoming fully aware of the
> inheritance relations, that is. ;-)

No, they can't want that (barring simple confusion).  The important bit is
that no code uses A directly for anything, ever.  The code uses D (and B)
and thus uses A's attributes, but it never uses A.  If the user wants just
D to be different, they customize it (to override some/all of what it
inherits from A, or to inherit from something else entirely).  If they
choose to customize A it is _because_ they want everything changed along
with it; they are preferring "consistency" to "specificity".

As for becoming aware, that's why the convention of "this face exists
solely for inheritance" must be specified.  But that's not hard for the
user to notice, so I don't consider it a problem.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.