One last Thread on *.FromText

I wanted to break this out from the rest of the discussions on the new framework… I will say my peace here and will soon stop bringing it up because one does get tired of hitting a wall.

Parsing text containing numeric strings with trailing characters is something I have to of a lot of, sometimes needing to be done many hundreds of times parsing text files to pull out specific numeric data while the user is waiting.

This is a need not just for Science and Engineering but often for some business applications too. I know items I buy usually have a units in the price like “each”, or “oz” or “gal” etc … So we are talking about something a RAD environment should make easy - and most do.

If Xojo won’t supply conversion methods like that in the new framework, how would one write a generic method in the new framework to get numeric values in that case when the numbers could be integers, reals and may be in scientific notation or not?

You can know up from if the number should be Real, integer or an amount of money with trailing text. (and when you don’t know type you van always assume a type of Real number be it double or single ). Yes I know it can be done…

But my next question would then be how does that method compare speed wise with using Val in the old framework?

That is very important to me too and i’m sure other too. As i said I often have to parse many files with many tab delimited fields with numeric data like that while the user is waiting. I suspect with the overhead of the new text class it would be hard for us to get speed you could potentially get under the hood.

BTW Norm I would solve the “INF” issue by ONLY throwing exceptions only for strings like INF* and NAN*. While in one sense they are “valid” numeric values, those truly are exceptional cases and likely indicate some type of input error.

Zero is fine for everything else as that is often what we want for that… And if not we can check WHEN WE GET A ZERO… You don’t design to optimize for truly rare situations in the real world. My suggestion makes a lot more sense for real world situations and provides a reasonable amount of safety IMO.

I have to say it seems that most languages have a conversion function that works like Val so hat behavior is what most expect, besides being convenient.

Xojo purposely not supporting that functionality in the new framework looks to be a very much a case as hubris… Xojo inc seems to think it knows better than the rest of the industry what we need to conveniently get numbers out of text. Heck even Swift supports it was well as of course VB … Years ago when I used a number of other languages I believe that all had functions that worked like Val.

Now let me ask is there really any point in writing a feature request for changing the behavior *.FromText methods or introducing say DataType.ValFromText methods in addition?

If Xojo inc is philosophically hostile to the idea I don’t want to waste my time. As I mentioned before i doubt the feature requests would get a lot of votes, but the way it works now in the new framework it would likely annoy a lot of users in the long run, which is not a good thing. The natives are restless as it is! :wink:

Now I don’t dislike everything you done!

Supporting localization in these function is a good idea. I would want that also in DataType.ValFromText functions if they were added, though I could live without that if the replace function is fast. Some equipment does put out numbers meant to be human readable so include commas… I deal with that now by doing ReplaceAll with “”.

  • Karen

You aren’t hitting your head against the wall- I wouldn’t worry about it too much. I believe I said we were listening in the other threads. :slight_smile:

FR #? I’ll sign on.

I like Paul’s suggestion of calling it Integer.ParseText, although just keeping Val isn’t a bad idea either.

DataType.ValFromText would work too.