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:
reading = Val(LogFileValue)
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
Catch err As InvalidArgumentException
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.