string vs text TypeMismatch with literal strings

  1. 5 months ago

    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 ...

    became complicated:

    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.

    Any suggestions?

    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

  2. Dave S

    Feb 9 San Diego, California USA
    Edited 5 months ago

    If you are using the "old framework" (ie. current) and therefore "Strings" and not "Text"
    than

    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

  3. @Dave S If you are using the "old framework"

    How do one pick to only use the old framework?

  4. Dave S

    Feb 9 San Diego, California USA

    you dont... you use features of one, and/or the other.
    don't use "TEXT" just use "STRING"...

  5. @Dave S 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"
    end if
    
    v = s
    
    if v = "Jose" then  //<--- throws a typeMismatch
    msgbox "It's all good!!!"
    else
    msgbox "This sucks..."
    end if
  6. Dave S

    Feb 9 Answer San Diego, California USA

    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

  7. @Dave S 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...

  8. Dave S

    Feb 9 San Diego, California USA

    bear in mind.. ."Xojo for iOS" uses ONLY "new framework"... .which in my opinion is "dumb" since Apple (ie. Swift) has "strings"...

  9. Markus W

    Feb 9 Pre-Release Testers #JeSuisHuman New Zealand, Auc...

    @Dave S 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 …

  10. Jason P

    Feb 10 Xojo Inc Texas

    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)."

  11. Dave S

    Feb 10 San Diego, California USA

    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.

  12. Jason P

    Feb 11 Xojo Inc Texas

    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.

or Sign Up to reply!