|
Boost : |
From: David Abrahams (dave_at_[hidden])
Date: 2008-05-25 01:53:42
on Wed May 21 2008, Vladimir Prus <vladimir-AT-codesourcery.com> wrote:
> Johan RÃ¥de wrote:
>
>> David Abrahams wrote:
>>> I was just reviewing the filesystem docs and came across "leaf()". I'm
>>> sure this isn't the first time I've seen it, but this time I picked up a
>>> little semantic dissonance. Normally we think of "leaf" in the context
>>> of a tree as being a thing with no children. An interior node like a
>>> directory that has files or other directories in it is usually not
>>> called a "leaf." I wonder if this is the best possible name?
>>>
>>> Is there a precedent we can draw on in some other language/library? In
>>> python, it's os.path.basename(p). Perl, php, and the posix basename
>>> command seem to do something similar.
>>>
>>
>> David is absolutely right.
>>
>> The name leaf is the result of conceptual confusion,
>> failure to distinguish between the tree structure of the file system
>> and the linear structure of a path.
>>
>> If possible, at this late stage, the names should be changed.
>
> <another universe mode>
> Of course, since boost.filesystem is used by exactly zero real-world
> projects right now (because nobody was able to grok the meaning of 'leaf'),
> it's OK to change the names to more sane ones.
> </another universe mode>
>
> <this universe mode>
> Given that boost.filesystem appears to be highly popular, and apparently
> users don't care about conceptual clarify of 'leaf', changing those names
> will basically cause everybody to change, or conditionally change, their
> code, without any practical benefit.
> </this universe mode>
I think conceptual clarity and the use of accepted terminology will be a
big deal in the future for those people coming from other languages and
environments, and if this library is successful that group will be way
bigger than the library's current userbase is.
-- Dave Abrahams BoostPro Computing http://www.boostpro.com
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk