Re: [boost] Re: Review: Boost.Threads

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.
This
> > 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
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 ;-)

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
'broadcast' either.

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.