Re: static virtual is a keyhole?

> Let me first try to clarify why it's important to me not to stretch the
> meaning of "keyhole" too broadly.  To me, all keyholes result from a
single
> error in thinking: imposition of a gratiutous constraint.

Taht is clear and reasonable.

> This is almost
> always use of a constant where a variable would be better

Though this is a point I don't agree.   Especially reading further:

> The value in identifying the keyhole PROBLEM
> (*singular*) is that it requires that software developers learn only one
> thing to be aware of.

YES! :-)

I believe I grasped that concept exactly that way.   It is a problem. One
problem. We run into manifestations which can take several forms, but
digging to the roots there is a singular motive behind.   And it is not
about numbers or element count.

It is, as I would put it:  _introducing an artificial constraint where no
constraint is needed_.  Just as in the "keyhole" parable: we could look into
the room through a window, but someone decided to shrink that window in
height, and also in width, so finally it is as big as a keyhole.    While he
could just leave it as is, and we would have the original size.

> Not all gratuitious constraints are keyholes.  For
> example, many web pages fix the size of their font.  This is a gratuitous
> constraint, but I can't find a way to make it fit the keyhole model.  It's
> a different kind of gratuitious constraint, one arising from a different
> kind of flawed thinking.

I'm not sure it is the best example reading the other posts, but I'm not
really familiar of details of webpage design.  Though I'm sure  follow the
thinking.

There is a clear cut of roles.  The designer here creates some final
product -- and want to fix some shape of it he thinks it's good.    Making
the pahe flexible to users jusy may not seem important -- as what 's
supposed to be the produxt is mainly the content.  The reader is a
"consumer" of the product in that final shape.   The consumer role is not to
take over the control, etc.

The cases I'm interested in are different.  Where the main reason of the
sytem is exactly they: provide the user a way to use the options, to
customize, to use the elements provided to his best interest.    IMHO a good
example is a coffee machine. :)
It will have a simple interface.  Insert a coin, and select options from
option groups:
A/ amount of coffee (single, double)
B/ amount of water (1,2,4,6,8)
C/ amount of sugar (0,1,2,3)
D/ amount of milk (0,1,2)
And a pair of buttons, "start" and "cancel".

The "options" map directly to some hardware elements, and the simplest
possible machine is just a mixer.    Shall there be constraints?   Maybe.
A good reason to disallow some combinations is a hardware limit.  If the
machine uses a small cup, using the max of everything may overflow.
Another reason may be budget.  an adwanced machine could ask the price
depending on option. For a one-price machine we may decide some combinations
too costy for us to provide.
So a poor design to solce the mentioned problems would cross some
combinations.  A good design would   assign "volume" and "price" to options,
and a function calculating total voulume or total price, then comparing to a
single maximum.  rejecting based on that, independently on the individual
options, or preset combination.

We arrive to tha ill thinking and "gratuitious constraints" when the
provider engage his mind thinkering "why on earth would anyone in sane mind
want 3 sugar with 1 water; or double coffe without milk"  or anythnk he
would not use.   And to "save the fool user" from doing "unreasonable" thing
he disallows some options.

It is important to see, that providing those combinations would not be a
"new feature" to implement.  The fearure is implicit, it is present in the
system.  nothing shall be done to have it.  Extra work is put ot in its
implementation, but in removement of functionality. And the thinking is "I,
the designer know better".    What is generally a failing assumptation.
Maybe it isn't when the design is created, but as time moves on, it still
fails.
As so many of those "max number" constraints were reasonable at some moment.
640k shuld be enogh. (Dos -- Gates)  2Gigs should be enough (Win32)  1 phone
number is enough.  1 mobile phone is enough. 1 email. 255 bytes in a string.
64k. some megs.  The list is countless.   I pretty well remember how 64k of
C64 was after the 1k of ZX81.  How 512k on the XT was huge. 640k really
seemed impossible to fill.  Then 4 megs was a huge memory in AT, and one
stuffed to the limit of 16megs was like a dream.  today the obsolete entry
level pcs enter with 128 megs and even the VGA card has 32 megs.
But we still use software created back then.  If one thought "let's put a
limit of 16 megs on vector size -- so much memory hardly exist" it didn;t
hurt anyone then.
I'd guess many of those combobox keyholes developed the same way.  One
designer counted the options, and used that size for the box.  Having fixed
amount of options doesn't ask for a dynamic limit.     Then someone else
dropped in another stirng -- and didn't adjust the interface.    Or for
screen problems -- a plenty becomes a problem only with big resolutions.  If
no one used so big screens when the thing was designed (or bigger than
something resoution was consodered exotic) it wasn't apperant in tests, and
the limit, the constraint was not even considered as a limit.

That is the real point -- to fight that problem we must point out how to
think, and NOT think with constraints.    To use only those really
reasonable for the current situations.   And Not putting in anything just by
thinking it is "not reasonable" or stupid.
We have two kind of users -- those who have a clue what they wont -- they
will not do unreasonable things, and if they want some feature, they need
it. They know better -- and the designer should not think he can foresee
anything.
The other group is clueless -- but what they get will not make sense anyway,
no matter that it is within some limits or not.  No amount of design can
help them, and we should not sacrifecie the real users in the doomed attempt
to help them.

> More specifically to your example, not all combinations of features make
> obvious sense.

Caught you red handed. :-)    The example is taken from a computer language.
There it is especially fruitless to ban some combinations on the "makes
sense" argument.  As the user (programmer) is not limited to a single
expression, statement, block, anything... and it is hopeless anyway to
analyse the "sensefullness" of the combination of repeated elements.  Then
why bother with ones within a single statement/expression, etc?
The program is not created in a random way -- write something then the
compuler can tell if it makes sense, but you write what will make sense in
the first place.

It is a frequent argument on different groups that "why it is not prevented
by compiler, language, anything to .... [say delete an object that we have
pointers pointing to elsewhere] ... and the general answer is, "don't do
it".
Really, some constructs are not allowed as that would make it hard to
impelment.  "what makes sense" is good to consider when a new proposal is
considered.  But not when we use what we already have there.

>   const volatile int z = 10;    // may z be placed in ROM?  may it be
>                                 // changed?

extern const volatile clock_t hw_clock;
// mapped to a device

volatile, as the hardware change the value, every read will provide the
actual time.
const, as writing to it will break he clock. Or open the garage door. Or
just set the clock to the given value -- but we don't want it through this
name.

> Setting aside what C++ says about the ROMability of z, my point is that
> it's not necessarily obvious that const and volatile make sense together.

And the point is: the designer shall not think in such terms at all.  If he
can't think up a use in 5 mins or 5 hours does that prove there can't be a
good use?   Shall we think if 'for' can be used in a body of another 'for'?

Or look this:
{
    int i = 0;
}
Does that make any sense?  I'm pretty sure not. a local is created, and goes
away.  We shall ban it.  Shall we ban it?    making no sense is not a reason
to ban something.
To ban something that happens to be there, working without touch we must
have a real reason.

> You say that you see "no sane reason" to disallow the combination, but I'm
> guessing that that's because you already know how C++ defines the
semantics
> of this combination.

We have 'goto' in C. It works fine within a function.  We have the same goto
in C++.  But it is not so free:  you can't goto through a 'ctor' to an area
where you would have the object in a bad state.    THAT is a good example
for a 'sane reason' to me. The designer knows the problem, and restricts the
use exactly to prevent that problem. And no more than that -- as you can
goto over that ctor if you go far away to see that object entirely gone.

There is a good reason not to have virtual template members. "no one
presented a clue how to implement that beast" is a damn good reason.

But "I dunno what to use that thing for" is no sane reason to me, and I
believe we would have a better world if that kind of thinking would be gone
entirely.

> Before those semantics were defined, one might argue
> that const and volatile were contradictory.

Well, if there IS a proof, that there is a contradiction, thet is certanly a
good reason.  My premise for this case was that const and volatile are
*disjunct* features, that implies they can not contradict.    I especially
selected that example thinking it is obvious -- if that point is
questionable, let's use any other example where there is no debate on well
separated behavior.

> Now, one might imagine a "missing feature combination" keyhole, but my
> objection would be that a missing combination of features is not due to
the
> same kind of underlying conceptual thinking that leads to the things I do
> call keyholes.

And i ask you to think it again. :)  As my point is exactly this:  I see a
very similar kind of thinking in those cases.   [And certainly not in _any_
case with feature combinations, see the valid constrints with coffe
machine.]

(And even if you consider it a different phenomenon, it may be good to have
a rundown in the book to summarize some tipical nuisance but "not keyhole"
cases, like you presented here.)

> Again, my goal is not to make the term "keyhole" cover as
> many situations as possible.  It's to define the term precisely and
> narrowly enough that when somebody says, "Hmmm, you've got a keyhole in
> your software here," pretty much everybody knows exactly what that means.

I think it's a good and reasonable goal.

> We already have plenty of terms that are so broad, nobody knows what they
> mean.  (E.g., "object-oriented," "pattern.")  My preference is to try to
> keep that from happening to "keyhole."

Khm.    Let me use some spice melange and predict the future.  There are two
paths. On one people find the idea interesting, and will use it. And it will
get out of your hands just like object or pattern or antipattern -- with
some bending here ant there, debates, and so on. Really losing a firm
definiton, but create a plenty of benefit to those willing to use it for
good. [trivia: can you define "table"?  Or the real-life "keyhole" using the
"classical view" ;]

On the other path people will say "yawn" and no one will give it a damn
besides a few dozen fans.

Gues you would like to see the first one happening -- and theer's no
contradiction, the idea shall not be broad at the start, it must be useful
in practice, and also interesting to catch attention.    Though especially
fight the borderst, cut away corner cases is likely not beneficial.


>I just thought of another reason why a missing feature doesn't "feel right"
to
me as a keyhole.  Consider again the physical analogy of trying to see the
contents of a room through a keyhole.  The keyhole doesn't keep you from
seeing
anything, it just keeps you from seeing everything at once.

Probably depends on the keyhole -- a plenty of them actually prevent to see
the corners or sides. :)

> A missing feature is something you can't see at all, because the author of
the software has failed to provide it.

But I agree with that.  Missing feature is missing feaure. If it is
genuinely missing, it is nothing like a keyhole.   I was trying to talk
about a distinction within features, those that were not added and those
that were removed.    Abot "restricted" or "banned" or "masked" features.

And like a keyhole is a mask on the window, the artificially restricted
featre is similar to it.

Paul