Page 2 of 2
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Thu Dec 19, 2013 12:42 pm
by Little John
Shield wrote:Little John wrote:...but a string alone can't be True or False, because it's no Boolean variable.
If you argue like this, then...
...should not be allowed as well, because "a string is not a boolean value".
Yes.
Little John wrote:Just use Boolean operators for Boolean variables, and string operators for string variables etc.
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Mon Dec 30, 2013 3:54 pm
by Mistrel
Aargh.. so much of my code is broken. I have years worth of code using this.
This is no small problem in my case. I used this feature in almost everywhere.
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Sat Jan 11, 2014 10:56 am
by Mistrel
This is driving me absolutely flipping bat-crazy. Not only am I inundated with compiler errors when linking in old code, but projects which do NOT need to be updated are requiring significant modification to work.
Additionally, I'm finding that some projects are behaving strangely with the latest release. This is causing MORE problems because it means I need to maintain separate code bases for similarly reusable code which is no longer backwards-compatible unless I go back and revise code I've already changed AGAIN!
For example.. I prefer the "If Not" syntax and have been swapping blank strings with Bool() but now I have to go back AGAIN and swap them with "If Not String.s=" for backwards compatibility.
This is still a major, major headache, not to mention that it's just not as pleasant to read as the older code.
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Sat Jan 11, 2014 11:15 am
by PB
> I used this feature in almost everywhere
A macro with file search/replace of your sources?
Code: Select all
Macro IsNot(string)
Not Bool(string)
EndMacro
If IsNot(Empty.s)
Debug 1
EndIf
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Sat Jan 11, 2014 4:39 pm
by BorisTheOld
Mistrel wrote:This is still a major, major headache, not to mention that it's just not as pleasant to read as the older code.
I agree, because the change isn't "logical". And it probably breaks a lot of code, given that PB has been around for 10 years.
The illogical thing about this change is that numeric data types are also not true binary state items. There is no such thing as a true 1-bit data type. An 8-bit byte can have 256 states and a 32 bit integer can have millions, but it's only a convention that 0 means false and everything else means true. So why is it wrong to assume that an empty string is false, and a non-empty string is true?
@PB
Like you I use macros to make my code more readable and to make it obvious that I'm making binary decisions. I've always used macros in my code to hide constructs that don't conform to standard coding practices. This can be really helpful when handling language "improvements", or when converting from one language to another. These days, my code tends to look like a perverted cross between Fortran, Algol, Basic, and Cobol.
Code: Select all
;
;===============================================
;
; Macro 107 : true if the item is an object
;
Macro IsObject (bvsDataParmName)
bvsDataParmName <> 0
EndMacro
;
;===============================================
;
; Macro 108 : true if the item is not an object
;
Macro NotObject (bvsDataParmName)
bvsDataParmName = 0
EndMacro
;
;===============================================
;
; Macro 109 : an empty string value
;
Macro Null
#sNULL_STRING
EndMacro
;
;===============================================
;
; Macro 110 : true if a string is empty
;
Macro IsNull (bvsDataParmName)
bvsDataParmName = #sNULL_STRING
EndMacro
;
;===============================================
;
; Macro 111 : true if a string is not empty
;
Macro NotNull (bvsDataParmName)
bvsDataParmName <> #sNULL_STRING
EndMacro
;
;===============================================
;
; Macro 112 : true if an expression is not zero
;
Macro IsTrue (bvsDataParmName)
bvsDataParmName <> 0
EndMacro
;
;===============================================
;
; Macro 113 : true if an expression is zero
;
Macro IsFalse (bvsDataParmName)
bvsDataParmName = 0
EndMacro
;
;===============================================
;
; Macro 114 : return a true value: -1
;
Macro True
#lVALUE_TRUE
EndMacro
;
;===============================================
;
; Macro 115 : return a false value: 0
;
Macro False
#lVALUE_FALSE
EndMacro
;
;===============================================
;
; Macro 116 : true if the object is not at end of file
;
Macro NotEof (bvsObjectName)
IsFalse(Get(bvsObjectName, exlEndOfFile))
EndMacro
;
;===============================================
;
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Thu Feb 11, 2016 11:42 pm
by Mistrel
This is still my biggest pet peeve of PureBasic 5.0. Fred, any chance you might revert this at some point? Pretty please?
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Fri Feb 12, 2016 7:46 am
by HanPBF
Just to be curious...
About how many lines of code do You talk?
Shouldn't it be possible with PowerGrep to change code with an even complex search and replace?
Maybe in multiple steps to first mark if-statements and then move forward.
I like the bool function as it goes in more type safe direction.
At the moment it seems to be useless; but if PureBasic-language evolves sometimes, this could be helpful.
If would consider even not use
Code: Select all
...
define MyInput.s = ...
if not MyInput ; implicit type cast
...
; but instead
if MyInput<>""
...
Regards
Re: Unwelcome changes with strings in expressions with Bool(
Posted: Sun Feb 14, 2016 5:14 am
by Mistrel
It's not just about updating old code. I LIKED the old behavior.