|
Boost : |
From: Kevlin Henney (kevlin_at_[hidden])
Date: 2001-07-20 14:35:20
> From: "Vesa Karvonen" <vesa.karvonen_at_[hidden]>
>From: "Kevlin Henney" <kevlin_at_[hidden]>
>> Have you considered using the name 'locker'? This is the one I tend to
>> use: a locker (the scoped locking object) locks (calls the member
>> function) a lock (the mutex).
>
>I'm not native English, but 'locker' sounds like the thing that you use for
>storing objects. ;-)
Quite correct, this is one of its meanings. Although it is worth
pointing out that "locker" has fewer meanings in English than either
"lock" or "guard" :->
However, the analogy is not lost with this alternative meaning: a locker
is an enclosed space that may be locked and unlocked ;-)
>Anyway, this and related idioms have many names such as:
>- 'guard' (http://www.cuj.com/experts/1812/alexandr.htm?topic=experts)
This naming convention is somewhat older than Andrei's stuff :-) You
will find it commonly used across much of the literature and in much
code.
>- 'sentry' (standard IOS library, TCPL)
Not a bad name.
>- 'proxy' (GoF)
Simply inaccurate if the object does not support forwarding semantics
:-(
>- ...
Tantalising ;-)
>So, I would propose simply appending lock with one of the above names. For
>example 'lock_guard'.
This is certainly a better name than auto_lock -- there is not much that
is "auto" about a lock that exists for the duration of an object's
lifetime rather than a block scope, which seems to be a common use for
another well known "auto" type :-}
>Personally, I have been using a class template 'locked', which is basically a
>handle to a lockable or guarded object/resource.
The problem is that "locked" is a description of state, ie a query or
state flag name rather than an object that performs an action.
Kevlin
____________________________________________________________
Kevlin Henney phone: +44 117 942 2990
mailto:kevlin_at_[hidden] mobile: +44 7801 073 508
http://www.curbralan.com fax: +44 870 052 2289
Curbralan: Consultancy + Training + Development + Review
____________________________________________________________
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk