From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-25 10:37:52
From: "Scott McCaskill" <scott_at_[hidden]>
> > It is a feature that signal/broadcast are unreadable by non-experts.
> > causes an immediate task-switch to documentation reading mode.
> That borders on intentional obfuscation.
No, I don't agree with the 'intentional obfuscation' claim. We don't invent
arbitrary new names with obscurity as the only goal.
> Classes and methods should be
> named according to what they are or what they do, respectively.
Absolutely agree; but this guideline is so general that it's nearly useless.
You can't name a method according to what it does (with minor exceptions)
because people rarely like 80+ character names. You need a 'mapping' from
'what the method does' to the 'acceptable identifier' namespace, and coming
up with _that_ mapping is the hard, and subjective, part.
I think that intuitive names imply intuitive semantics. Notify_one and
notify_all are, IMO, intuitive names. Are the semantics of those functions
equally intuitive? Religious issue? Then why not use POSIX as a tie breaker?
> > unblock_one_waiting_thread/unblock_all_waiting_threads are the
> > self-descriptive, no-documentation-necessary alternatives, but I don't
> > 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 ;-)
We'd be naming the methods for their _only_ effects:
"The pthread_cond_broadcast( ) function shall unblock all threads currently
blocked on the specified condition variable cond."
"The pthread_cond_signal ( ) function shall unblock at least one of the
threads that are blocked on the specified condition variable cond (if any
threads are blocked on cond)."
signal/broadcast don't notify. ;-) To be fair, they don't 'signal' or
Don't get me wrong, _I_ personally don't have any problems with either
naming scheme. I can handle abstract concepts where 'signal' doesn't signal,
'notify_one' doesn't notify and may unblock two threads, 'throw()' doesn't
mean that a function has an empty throw specification, and 'X: private
noncopyable' doesn't mean that X inherits privately from noncopyable. It's
other people that can't get the joke. ;-)
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk