Giving the whole discussion about strings vs text and the future of API 2.0; I decided to stick using strings in my new projects.
I have no issues with encoding, or with the use of the new frameworks, and my code is fairly disciplined as to use only strings.
I discovered that literal strings are actual “TEXT” or “TextLiteral”. This is super annoying because there are so many ways to end up with a value which is not explicitly declared as a string and you get TypeMismatchException left and right. Specially with auto, dictionaries, etc.
Is even worst having to assign to a str variable or force a cast to string with things like ( anEmptyStringVar + aValue )
Simple things like this:
if value = "jose" then ...
if value.toText = "Jose" then
if ctype(fnReturnStringAuto(),string).toText = "Jose" then
if fnReturnString().toText = "Jose" then
dim s as string
if value = s + "Jose" then
I dont see how Xojo can harmonize STRING and TEXT so that we have a migration path that does not break the current projects. To fix this at some point they will have to break compatibility, or introduce yet another type.
Im really tired of all the casting/coercing (is worst than java) In my head I think is a best bet to stick with TEXT instead and start re-writting my code.
If you are using the “old framework” (ie. current) and therefore “Strings” and not “Text”
if value="jose" then
works perfectly, since that is how it has been since before the “new framework” saw the light of day
So you must be doing something that is out of kilter… since with “strings” no casting is required, and a string variable compared to a quoted literal value is a simple compare.
I know this to be true, since I never adopted the “new framework” and I have no need to cast anything string related
How do one pick to only use the old framework?
you dont… you use features of one, and/or the other.
don’t use “TEXT” just use “STRING”…
This is my problem, I create a blank project and just run the following code:
dim v as auto
dim s as string
s = "Jose"
if s = "Jose" then
msgbox "Works as expected"
v = s
if v = "Jose" then //<--- throws a typeMismatch
msgbox "It's all good!!!"
msgbox "This sucks..."
AUTO is like VARIANT (and in my opinion, : should never be used if at all possible)
and if you read the LR in regards to AUTO… you will see it uses TEXT (ie. “new framework”)
You said string literals were treated like TEXT… NO, the auto you created is TEXT, the literal is still a “string”
Best I can tell… VARIANT is old framework, AUTO is new framework
Wow!, Thanks Dave, that answers that issues. Tested with variant and it works as expected. All my issues were with dictionaries and auto variables.
I guess auto does not respect “string” as a type.
I have a couple of libraries that I share with IOS projects that are using auto, so much for that…
bear in mind… .“Xojo for iOS” uses ONLY “new framework”… .which in my opinion is “dumb” since Apple (ie. Swift) has “strings”…
Xojo has made some questionable decisions in the recent past
Swifts “string” is much more like the new frameworks Text than it is the classic frameworks String. The description of Swifts string is “A Unicode string value that is a collection of characters.” and Xojo text is “The Text type is used to store textual information (unicode).”
My point was that the Swift “String” is a single datatype that handles all character manipulations using functions that correspond with direct analogs to the “String” datatype in most any other language, Xojo included. So then, why can’t doesn’t Xojo do the same thing. This would extend the “functionality” and yet retain backward compatiblity.
Text was intended to be exactly that - a single data type for textual data just like in Swift. And the classic “binary data” behavior that the classic string had was encapsulated in MemoryBlock and MutableMemoryBlock. This is analogous to how Swift uses String and NSData for text and binary data.