Hyrum K. Wright wrote:
> Firstly, I need to apologize. My previous mail on this topic was a bit
> dismissive of Blair's comments, and shouldn't have been. I was getting
> defensive of those commits, and it showed. I really do appreciate the
> review; it helps me learn to be a better hacker. Thanks.
Hi Hyrum,
Thanks.
> Branko Čibej wrote:
>> Hyrum K. Wright wrote:
>>> Interesting. The standards committee must have included the implicit
>>> conversion operator capabilities for /some/ reason, though. If the only
>>> reason *not* to use it is that there's "too much magic" going on, I'm
>>> not sure that I completely buy that. I'm just concerned that we're
>>> throwing the baby out with the bathwater in an attempt to make things
>>> foolproof.
>>>
>> Like many interesting features of C++ (and C), implicit conversions can
>> be indispensable in some cases, but are dangerous most of the time. If
>> you don't need them, don't use them.
>>
>> In this case, the you can get the syntactic sugar by adding inline
>> overloaded functions that accept a const Path& to wrap the API
>> functions. The effect on the syntax is the same, but you avoid the
>> dangers of the implicit conversion being triggered when you don't
>> actually want it, due to an all-to-easy programming error.
>>
>> To turn your argument around: The standards committee included the
>> 'explicit' keyword so that programmers can create single-argument
>> constructors that aren't implicit conversions precisely because implicit
>> conversions are so inconvenient in the general case.
>
> So, I've been thinking about this for quite a bit today. I even googled
> around for a bit to see what the general feel was about implicit type
> conversion. I was surprise to find that it was almost uniformly the
> same sentiment which Blair and Brane have shared. It seems that
> implicit type conversion is almost universally considered Evil, and to
> be avoided; a feeling I was not aware of.
>
> The method mentioned above is a valid one, but also feels like overkill
> for our use case. The functions in which we've made the changes *are*
> the wrappers, and it would be redundant to introduce yet another
> wrapping layer just to provide syntactic sugar.
>
> So, the simplest thing seems to just revert r24541, r24557 and r24558,
> and see where we go from there. I may wait a couple of days to do that,
> though, to see if others want to chime in on this conversation.
+1.
> Thanks again for the input!
Thanks for being open!
Regards,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 13 19:11:01 2007