I don’t mean this to be a rant but I really think Xojo needs to address text/character handling in their framework as a matter of urgency.
As most of us know, there are two datatypes available to handle textual content in Xojo - String and Text. The Text type is available on all platforms whereas String is not available on iOS. Whilst personally I prefer the syntax of the Text type and the guarantees it provides regarding encodings and it’s better handling of Unicode characters, It is dog dog slow on Windows and Linux. So slow as to be functionally unusable in my use cases (language hacking / parsers / runtimes, etc).
The String type on the other hand is really fast. Wickedly fast on the desktop for the things I need it to do which is great. Yes I know there are tradeoffs regarding encodings and the mixing between bytes and characters, etc but it is simply way faster than the Text type. I also really dislike its 1-based offsets (compared to Text which is 0-based).
Xojo has already told us that the Text type has been de-emphasised (as of 2018R4) and we should use the String type going forwards. I know from first-hand exposure at XDC that the Android target uses the String type. We can all see the problem here though can’t we? There is no alternative for iOS projects at the moment. No doubt Xojo will bring the String type to iOS but there has been no word (and the engineers were very quiet about this at XDC) about when this will happen.
Why is this such a big deal?
Well, I write parsers for fun and for money. I recently launched a Markdown parser for example and I maintain a complex scripting language. Both of these I want to run on all the platforms that Xojo supports - especially iOS. That’s why I pay so much every year for a Pro license. Currently, I have to maintain two Markdown parsers - both 7000 lines of code and both having to use different data types (String vs Text) but the same logic. Porting between String and Text is a nightmare. Thanks to the one and zero-based offset differences and much more evil subtle differences (like how .Split works for instance) makes this really very tedious.
I really think it’s unacceptable that this situation exists. I have rewritten Roo three times over and the performance with Text is abysmal on Windows and Linux so I’m forced to use String. When I say abysmal I mean the time difference between macOS (milliseconds) and Windows/Linux (minutes sometimes) is unacceptable. This means it won’t work on iOS. I simply don’t have the time to maintain two separate code bases for the same product because Xojo is currently incapable of offering a truly cross-platform solution for text handling. This is not an edge case - text handling is probably tone of the most common operations. Xojo’ s major selling point has always been and still is its ability to allow a developer to “write-once, deploy everywhere”. This is becoming increasing less true.
I’d be interested to hear how people deal with this issue and I’d really like to hear what Xojo’s position on this is. Please bring String to iOS!
Well, we know that eventually API 2.0 will be migrated to iOS. API 2.0 uses String instead of Text and Variants instead of Auto.
Personally I wouldn’t write anything using the Xojo framework unless forced to as it has a limited lifespan and limited functionality. The Xojo framework will be around for a while but it most likely will not receive many (any?) bug fixes. API 2.0 is where everything is headed (and eventually iOS too).
The Xojo framework and Text and Auto were implemented to solve very specific issues (not going to get into them here) and the community mostly rejected those solutions. API 2.0 is Xojo taking the best ideas of the Xojo framework and moving them into the global /classic framework.
What’s going to stink for the 3rd party developers is writing code that works in both worlds for a while. And then switching over to API 2.0 at some point in the future (say 2 years?) so you’re most likely going to have to rewrite it again.
“Text” vs “String” supposedly resulted because the iOS framework could not support “String”… something I find rather interesting since ObjC and Swift DO support a String datatype which is for the most part closer to what Xojo calls a String.
And (my opinion) everything that is under that umbrella of the “Text” datatype should have (and could have) been made extensions of the “String” datatype and none of this confusion would ever have existed … That being said, I do believe that this is part of what API 2.0 will address.
Now I do not use Xojo for iOS projects (for reasons I think I have made abundantly clear in the past), and only use STRING in Xojo desktop projects.
A possible solution that would help towards “future proofing” you iOS app, is write you own STRING class based on TEXT.
This way in the future when “STRING” beccomes native to “Xojo for iOS”, you can simply retire you class with little to no other code changes
I think Turkish is a pain point for String as it doesnot handle things correctly there
Text does
[quote=446697:@Garry Pettet]Why is this such a big deal?
[/quote]
I assume you mean “why cant string be ported to iOS quickly?”
String as a data type maybe - but then what do you do with everything else that might need it ?
And once you start there you might as well be doing API 2.0 for iOS
Which is when I would expect to see it since it really is a framework rewrite for iOS
Xojo’s “string” is not ObjC or Swift string
Its an entirely custom data type and implementation
Text is based on built in libs in iOS and macOS, and ICU on Windows & Linux
And TEXT does NOT support the dual “textual data” / “bag of bytes” weirdness that String did (which is and remains a HUGE reason people have bugs in their code)
[quote=446700:@Dave S]A possible solution that would help towards “future proofing” you iOS app, is write you own STRING class based on TEXT.
This way in the future when “STRING” becomes native to “Xojo for iOS”, you can simply retire you class with little to no other code changes[/quote]
That is a “good” solution in that it would solve my immediate code portability issues but it adds overhead that reduces performance.
[quote=446701:@Norman Palardy]I assume you mean “why cant string be ported to iOS quickly?”
String as a data type maybe - but then what do you do with everything else that might need it ?
And once you start there you might as well be doing API 2.0 for iOS
Which is when I would expect to see it since it really is a framework rewrite for iOS[/quote]
I completely understand that all the methods that use Text would need rewriting on iOS and it would indeed amount almost to a complete framework rewrite. I would argue that that is as important (if not more important) than, let’s say, constructing a new framework for Android when the existing iOS one is not fit for purpose. Additionally, iOS is a huge market - one that Xojo doesn’t seem to be focussed on.
I don’t want to take Dave’s approach and ditch Xojo for Swift or another tool for my iOS work because overall I do like Xojo very much. I worry though that issues like this start to make the eye wander and that can’t be good for the community.
I thought there already was a project that was a pile of “Classic wrappers” for the ne framework so on iOS you could kind of write “Classic” code but under the hood it was using the new framework ?
I can’t recall any cases in the last 18 years and 3 months since I first purchased RB that the duality has ever ever caused a bug for me…
I actually find the duality convenient, and take advantage of it in certain situations. BTW using variants have never caused me an issue that I can recall either.
I can assure you that while I was at Xojo there were a lot of bug reports that were because of this problem
Text 100% eliminated that issue
Variants had similar issues because they lead to apparently “magical” conversions that silently may NOT be doing what you intended (and then they might be doing exactly what you intended) IF you NEVER use a variant without the explicit accessors then you probably wont have these issues
Variants in the IDE were responsible for a very decent number of bugs I fixed over the years
