Re: [boost] Re: [filesystem] Operations predicates

From: Peter Dimov (pdimov_at_[hidden])
Date: 2005-05-04 13:41:52

Rob Stewart wrote:
>> From: "Peter Dimov" <pdimov_at_[hidden]>
>> Rob Stewart wrote:
>>> From: "Peter Dimov" <pdimov_at_[hidden]>
>>>>
>>>> I don't view overloading for overloading's sake as improvement;
>>>> there's nothing wrong with giving different names to different
>>>> behaviors.
>>>
>>> These functions do very nearly the same thing.  That seems an
>>> ideal case for overloading.
>>
>> This particular case is on the fence. One could think of the
>> overloaded interface as a typesafe approximation of
>>
>> status_return_flags status( path const & p, status_option_flags
>> flags = status_option_default );
>>
>> with follow_symlink being the only option flag at the moment.
>
> OK.  I'm missing your point, though.

My point was that altering behavior with response to a "flags" or "options" 
argument is an established idiom, and this case can be viewed as an 
application of that idiom, if one squints hard enough.

>> In general, though, excessive overloading should be avoided. My
>> usual litmus
>
> I agree wholeheartedly that "excessive overloading should be
> avoided."  I don't see this as excessive overloading.
>
>> test for appropriate overloading is: can you tell what this does:
>>
>>     f( x, y );
>>
>> without looking up the exact types of x and y.
>
> You can never tell in C++.  Is "f" a macro?  What is the scope of
> the call?  "f" is hardly a telling name, so how can one determine
> what f(x,y) does for any pair of arguments?

In the above, "f" is a placeholder for the actual function name.

> All of those questions aside, how does this apply to the case
> before us?

It doesn't. It was an explanation of the general principles that guide me to 
look for compelling arguments in favor of overloading and reject it if there 
are none, rather than look for compelling arguments against overloading and 
reject it if there are any.