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

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

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
> 

Hyrum,

Thanks!

Regards,
Blair

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesubversion.tigris.org
For additional commands, e-mail: dev-helpsubversion.tigris.org