Stewart, Robert wrote:
Mateusz Loskot wrote:
Recently, I've participated in a very interesting discussion, on ACCU members mailing list, about prefixes and suffixes like Base or _base nad Impl or _impl, as misused, irrelevant and confusing, meaningless, etc. For example, how to properly name elements of PIMPL idiom and similar.
As has been noted, if a class is a private, implementation detail, then some naming convention for that purpose is useful. I've seen "IC" used as a prefix to mean "implementation class." I've seen "Impl" or "_impl" as a suffix for the same purpose. These names indicate that they are not for library client use, even if they happen to be visible.
Yes, I've seen exactly the same use if these. It looks _impl, _base, all these are conventions well settled in the C++ world. I don't mind using them myself.
During the discussion I suggested that 'detail' is a good name for namespace dedicated to implementation details being not a part of public interface of a component. I got answer that it as the same issues (it's meaningless) as Impl etc.
While I've never been comfortable with "detail" and greatly prefer "details," the point is that it is a namespace, nested within another, more meaningfully named namespace, that holds implementation details that should be ignored by those using the enclosing namespace. There's no need for a name with any more meaning than that in many cases.
Understood. I've been following the same and I'm comfortable with it, however during recent discussions made me asking myself if and where thing could be improved.
However, it is quite reasonable to nest other namespaces within detail(s) in order to segregate details, all related to the outer namespace, by purpose. That is, if there are too many unrelated implementation details in the foo::details namespace, then foo::details should be subdivided.
Yes, makes sense to me.
It raised some questions for myself, being interested in improving my craft, I would like to learn better about the name of namespace detail. I use detail name myself. Any better names for bucket with implementation details?
Any time there is value in grouping things by a categorical name, do so. However, when those are implementation details of something else that should be visible to clients, then those details should be in a namespace like "details" to set them apart.
Very well said. I'll take it as a rule and definition of how to use namespace details. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net