[Gambas-user] INC and DEC on BOOLEAN data...

[David Yoder]

To me it seems that this is much to do about nothing!

Success = Not Success

does not imply boolean function unless Success is known to be
declared boolean. The programmer could be invoking the binary
complement of Success.

The best implication of boolean that I know is the assignment of
True or False.

I know that many programmers use increment / decrement with boolean
objects and that many use int objects as though they were boolean, while
that may have me doing a mental frown, it's a so what! Not something I
would do as a professional.

Dave

Paul Horechuk wrote:
> On May 11, 2008 11:45:44 am Benoit Minisini wrote:
>   
>> On dimanche 11 mai 2008, Stephen Bungay wrote:
>>     
>>> Benoit Minisini wrote:
>>>       
>>>> On dimanche 11 mai 2008, you wrote:
>>>>         
>>>>>    IMHO this is broken thinking. It might be a little more typing to
>>>>> use VarName = NOT VarName but it is decidedly more transparent as to
>>>>> what datatype 'VarName' is and what is being done to it.
>>>>>
>>>>> Success = Not Success
>>>>>
>>>>> vs
>>>>>
>>>>> INC(Success)
>>>>>
>>>>> DEC(Success)
>>>>>
>>>>>    In the first example it is very clear what is being done, even when
>>>>> Hungarian notation is not being used, whereas in the second example
>>>>> all that is clear is that a value is being incremented or decremented.
>>>>> INC and DEC implies a change in direction (up or down) to a numeric
>>>>> value, while NOT implies a change in state, which is more analogous to
>>>>> a toggle.
>>>>>
>>>>>    I think, and perhaps I'm wrong on this, that a 'data type mismatch'
>>>>> error is the proper response to those trying to INC or DEC a boolean.
>>>>>   Sorry, I just had to reply, when I see things like this it makes me
>>>>> cringe, like someone dragging their fingernails on a blackboard makes
>>>>> me cringe.
>>>>>
>>>>>
>>>>> Kindest regards
>>>>> Stephen Bungay
>>>>>           
>>>> Boolean and Integer values can be converted into each other in Gambas:
>>>>
>>>> True -> -1
>>>> False -> 0
>>>>
>>>> 0 -> False
>>>> Any other value -> True
>>>>
>>>> Incrementing or decrementing a boolean variable actually incremented or
>>>> decremented its integer converted value.
>>>>
>>>> INC False -> Inc 0 -> 1 -> True
>>>> INC True -> Inc -1 -> 0 -> False
>>>>
>>>> DEC False -> Dec 0 -> -1 -> True
>>>> DEC True -> Dec -1 -> -2 -> True ?
>>>>
>>>> Weird, so this was fixed in Gambas 
>>>>         
> 2.6http://www.directdial.com/LX.AJA0X.226.html, so that DEC True -> False.
>   
>>>> Otherwise, you will have to remember that INC toggle, but not DEC. I
>>>> found that too complex for my own brain.
>>>>
>>>> This is coherent with the common behaviour of Gambas. I mean you can
>>>> INC or DEC dates too, as Date and Float can be converted to each other.
>>>>
>>>> You can ignore this feature if you don't like it. Anyway, it cannot be
>>>> removed in 2.x for backward compatibility reasons.
>>>>
>>>> I could remove it in 3.0, and replace it by a NOT instruction that
>>>> would do the same thing only for booleans:
>>>>
>>>> NOT MyMenu.Checked ' for example
>>>>
>>>> Regards,
>>>>         
>>>    Yes, just because the feature is there doesn't mean the programmer
>>> (me in this case) has to use it. Or, as I've become fond of saying,
>>> 'Just because something CAN be done a certain way doesn't mean it SHOULD
>>> be done that way'.
>>>    INC and DEC makes sense on Dates since it implies a direction, into
>>> the future or back in the past, as opposed to the state change of On or
>>> Off, True or False a boolean value implies.
>>>
>>>    Personally I think I'll just stay with the already implemented BASIC
>>> syntax and use;
>>>
>>> MyMenu.Checked = NOT MyMenu.Checked
>>>
>>>    as it is clear as to it's intent. With typeahead already working to
>>> reduce typing there is little in the way of extra burden to the
>>> programmer as far as keystrokes go.
>>>
>>> IMHO, creating a 'NOT' instruction confuses things further since;
>>>
>>> MyMenu.Checked = Not MyMenu.Checked
>>>
>>> and
>>>
>>> NOT MyMenu.Checked
>>>
>>>    would produce the same result, however the latter looks more like an
>>> incomplete conditional than an assignment statement.
>>>
>>>    IMHO it is a good idea to Deprecate the INC and DEC on BOOL datatypes
>>> in Gambas 3.0.
>>>
>>>    GAMBAS is your baby Benoit, and you have done the Linux community a
>>> great service with it. I really have no place making any suggestions and
>>> thank you for taking the time to read my thoughts on the subject,
>>> however naive they might be.
>>>
>>> Stephen Bungay
>>>       
>> No problem. But if you are the only one people that is disturbed by this
>> semantic, maybe I won't remove it. On the other hand, if many many people
>> cry, I will!
>>     
> I have to side with Stephen on this. Allowing INC and DEC on Boolean is just 
> plain bad form. What's next, INC(Char) or INC(File)?
>
>
>
>