[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r24557 - trunk/subversion/bindings/javahl/native

From: Blair Zajac <blair_at_orcaware.com>
Date: 2007-04-16 23:37:04 CEST

Hyrum K. Wright wrote:
> Blair Zajac wrote:
>>> 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.
> Done in r24595.
> -Hyrum




To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Apr 16 23:37:22 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.