From: Scott McCaskill (scott_at_[hidden])
Date: 2001-09-25 09:49:33
> A case for signal/broadcast:
> * Q: Why? A: POSIX.
This (and existing literature) are the strongest arguments in favor of
> * Q: notify_* readable by non-experts, signal/broadcast not?
> It is a feature that signal/broadcast are unreadable by non-experts. This
> causes an immediate task-switch to documentation reading mode.
That borders on intentional obfuscation. Classes and methods should be
named according to what they are or what they do, respectively.
> notify_one/notify_all are readable enough that a non-expert would be
> to _not_ check what their precise semantics are - and get burned.
One could make that argument for any well-named, non-trivial function. API
names are meant to be mnemonic, not substitues for documentation.
> unblock_one_waiting_thread/unblock_all_waiting_threads are the
> self-descriptive, no-documentation-necessary alternatives, but I don't see
> anybody lobbying for them. ;-)
notify_one/notify_all are a reasonable compromise between brevity and
descriptiveness. Besides, we can't use
unblock_one_waiting_thread/unblock_all_waiting_threads, or we'd be naming
the methods for their side effects ;-)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk