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

Sun May 11 23:23:01 CEST 2008

Just adding my fourpence worth; I agree that Success = NOT Success doesn't 
necessarily imply a boolean operation is being executed, but it is a MUCH 
stronger hint that this is the case than an appearent attempt to increment or 
decrement a value.

There is a world of difference between type punning and type coersion. One 
requires/presumes an understanding of lower level architecture and the other 
is an attempt to make knowledge of the underlying structure unneccessary.

The first time I came across type coersion was in Sinclair SuperBASIC in 
1983/4. It was a huge leap forward in making programming a more human 
friendly process and part of an overall strategy in that language to hide the 
messy irrelevant details and make BASIC more readable. It wasn't until the 
Turbo compiler was introduced years later that the concept of designating 
types for numeric variables was introduced. But I digress.

The ability to apply INC and DEC to boolean variables does nothing for data 
abstraction or human readability (surely these are two important goals for 
every high level language?). Perhaps people who see nothing "wrong" with this 
apparent abuse of logic and language are more at home with lower level 
languages (such as C) or do not have English as their mother tongue.

I also think it is a huge mistake to say that some typographical convention 
should be used in naming the variable to make it clear that the "INC" or 
"DEC" operation is in fact the boolean operation "NOT". Many people, myself 
included, believe that reintroducing an expectation that the reader of a 
program needs to know the underlying structure of the storage used for a 
variable merely discourages good programming practices; use meaningful names 
for variables and functions and declare them close to where they are used. 

If your code requires an understanding of the data type being stored in a 
variable for a reader to understand the code then perhaps there is something 
else wrong. If the declaration of a variable is only a few lines away at the 
start of the function/procedure then it should be easy to refer to if needed.

If we are voting, then I vote for the official deprecation of INC and DEC on 
boolean values.

On Sunday 11 May 2008 18:32, David Yoder wrote:
> 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)?
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/java
>one _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user