Re: static virtual is a keyhole?

I'm sorry I've been so slow to respond to postings to this mailing list,
but I was traveling and now I'm trying to dig out, plus I have to focus my
energies on C++ these days.  But please keep the discussions going, I'm
definitely interested and reading!

At 08:17 PM 9/26/2003, Balog Pal wrote:
>In C++ member functions can be static, or can be virtual.
>However they can't be static and virtual at the same time.
>
>Currently there's a discussion on both csc++ and clc++m showing that
>implementig virtual statics in the compiler would be trivial. And the
>functionality is needed by programmers, who currently must use duplicate
>functions introducng redundancy.
>
>Looks like a case of a keyhole to me.

Yes, but not a *gratuitous* keyhole, hence not the kinds of keyholes I want
to focus on.  This is from a posting I made on July 25:

  I'm pretty happy with my definition of a keyhole as an arbitrary
  restriction on something you can see or express.  In that sense, failure to
  provide a feature a user can imagine could be considered a keyhole.  Within
  the realm of keyholes, however, are what I call *gratuitous* keyholes --
  keyholes without a decent reason for existing.  A gratuitous
  keyhole has two characteristics:
    1. It's part of a specific feature that the implementer has decided to
       offer.  
    2. Avoiding or enlarging the keyhole (remember that if you have to have a
       keyhole, bigger is better) is not terribly difficult.
  My focus is on gratuitous keyholes, i.e., ones that should be addressed
  (due to (1) above) and that are practical to address (i.e., satisfy (2)
  above).  Also, my interest is in keyholes in *software*.
  
  With that said:
    - The car radio button keyhole is a hardware issue, hence outside the
      realm I'm interested in addressing.
    - The lack of features in a music player isn't a keyhole, because it
      fails (1) above.
  Let me amplify on the idea behind this second example.  Suppose I have a
  program that doesn't let me change the colors of the text.  If that's the
  case, I can't complain about this lack of capability as a keyhole (due to
  (1) above), though I might complain on other grounds.  But let's say that
  the program DOES offer the ability to change text color, but it only gives
  me a choice of 10 colors.  As a keyhole, this is questionable until somebody can
  establish that offering an unlimited number of colors isn't terribly hard.
  (An argument that might clinch that point would be the availability of a
  simple text-color-selection API on the platform where the program runs.)
  But let's suppose that the 10 colors are shown in a listbox that shows only
  8 at once.  Clearly I want that to be a keyhole, though the draft chapter I
  have now doesn't establish it, because I haven't yet shown that avoiding
  the keyhole is easy.

It's important not to dilute the impact of calling something a keyhole.  If
every feature that somebody wants but that isn't provided is a keyhole, the
term is close to useless.  

Scott