My first language was AppleSoft BASIC. I can say with certainty that Xojo/REALbasic was never BASIC. Not even remotely close. Aside from a few keywords, what Xojo does share with BASIC is simplicity. The idea, for example, that every line doesnāt have to end in a semi-colon.
I would be curious as to what things in the new framework you see as more complex. There are certainly some new ways to doing things. Sometimes new and feel (at least initially) more complex because itās new. Converting from text to a number is different. But far from being less readable, it seems more readable to me. Bob Keeney wrote about converting text to numbers being more difficult but I donāt see that. He feels the conversion rules should be more liberal. Thereās an argument to be made there but it comes at a price. For example, today if you pass āA10ā to the VAL function, you get 0. Why? Because the rules of VAL say that once we hit a non-numeric value, the value is numerically invalid. But this rule is something you have to learn about to know it works that way. And returning 0 is a lousy way to indicate that since 0 is a perfectly valid number.
I suppose an argument could be made that any of the numeric conversion functions should strip all non-numeric characters and then convert the value if for no reason other than convenience. So converting ā$123ā would become 123. And passing ā$123.55ā to Integer.FromText would drop the decimal. I think thatās logical, though there may be implications Iām not considering. However, even in that case, youād have to consider locale. In Europe, the decimal separator is a comma whereas in the US itās a period. I suppose the conversion functions could default to the current locale unless one is optionally specified.
For now, the obviously solution is to make sure that what you are passing to a numeric conversion function is, in fact a valid numeric value. Thatās something you should be doing already anyway with VAL so you donāt get invalid results. Assuming youāve done that in both cases, the difference between the old and new frameworks, in terms of numeric conversion is minimal. IMHO, Bobās example is an academic one. I can see how he would come up with it when exploring the new framework. However, I think in a real world situation, itās going to be less obvious. Considering reading values from a log file:
Old Framework:
reading = Val(LogFileValue)
New Framework:
reading = Integer.FromText(LogFileValue)
The numeric conversion functions in the new framework require certainly require a little more typing. However, itās far more readable considering that conversion doesnāt always happen within eyeshot of the declaration of the type. In the first example, I have no idea what Iām going to get. In the second example, Iām certain that Iām converting to an integer. And if I have forgotten and use Double.FromText instead, Iāll know it at compile time. The latter is slightly more complex in that you have to think about the type of number to which you are converting, that is not implicit, but implicit often gets people into trouble. Thatās why Xojo is a statically-typed language for example.
In Bobās example, heās letting the function do the type checking. And he admits that in his post. But we know from experience that we should not do it that way. We should make sure we have a valid numeric value before we convert it to a number. Depending on Val to return 0 we know is not good or obvious. If you are going to depend on the converting function, at least the new framework conversion functions will throw an exception so you can test for that. In fact, you could even use them to write your own function that you use to first determine if the value is numerically valid or not:
Function IsInt(input As Text) As Boolean
Try
Call Integer.FromText(input)
Catch err As InvalidArgumentException
Return False
End Try
Return True
End Function
What we have seen over the years is that people play fast and loose with functions like Val only to create hard to find bugs later on because thereās implicit conversion going on and they frequently donāt know or remember the rules. The new framework makes these kinds of bugs far more difficult to accidentally create.
