[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: 2007-04-16 23:18:51 CEST

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.


Received on Mon Apr 16 23:22:45 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.