Please "Un-deprecate" `Text`

Hopefully not LenC, LeftC ! We do not live in 1980 where you need to save bytes.

Is no reason in 2021 to not have code readable by having full names CharacterLength, LeftCharacters, etc

1 Like

65399 - A way to navigate/manipulate strings by characters
<https://xojo.com/issue/65399>

3 Likes

DateTime.ToString (loc As Locale = Nil, dateStyle As DateTime.FormatStyles = DateTime.FormatStyles.Medium, timeStyle As DateTime.FormatStyles = DateTime.FormatStyles.Medium) As String

vs

aDate .LongTime

6 Likes

I suspect Nicholas is referring to how API2 adds extra complexity:

// API 1
dim t as new Timer
t.Mode = Timer.ModeSingle


// API 2
dim t as new Timer
t.RunMode = Timer.RunModes.Single

So, you’d be a fan of:

String.CharacterLengthZeroBased
String.CharacterLeftZeroBased

etc?
:stuck_out_tongue_winking_eye:

2 Likes

The major issue with this is performance. Me splitting the string into characters and then iterating through that and appending individual characters when I want to use a custom extension like String.LeftCharacters will be slower than Xojo’s C++ framework doing that for me.

Better still - why can’t I just use the existing Text data type that already exists and already does this?? Oh right I can’t because it’s been unnecessarily deprecated…

1 Like

It’s really bad we didn’t have this topic before API 2 showed up.
Then we could have had Middle() and Length() to take an enum parameter to define if you like to have Bytes, CodePoints or Characters.

ñ as bytes is 3 for UTF-8, ñ as code points would be 2 and ñ as character would be 1.

Still please don’t change existing functions as we otherwise look for a way to cut characters without those, e.g. to remove ~ from n.

1 Like

Overly long names for things…that is bad enough but combined with the flakey autocomplete that sometimes requires full specification when it should not be needed makes it worst.

-Karen

2 Likes

Oh this mess just gets better.

Var s = "a☺️b"
Var chars() As String = s.Split("")

// chars(0) = "a"
// chars(1) = "☺"
// chars(2) = EFB8 8F (non-visible character)
// chars(3) = "b"

From the String docs:

Use the Split function to create a new String array from a list of elements (or fields) that are separated by a delimiter. If the optional parameter, delimiter, is not passed, a single space is assumed as the delimiter. If the delimiter is an empty string, the source string is split into characters.

Compared to the correct behaviour if you use Text:

Var t = "a☺️b"
Var chars() As String = t.Split("")

The (ugly) and slow workaround for String is:

Var s = "a☺️b"
Var chars() As String
For Each c As String In s.Characters
  chars.Add(c)
Next c

I’ve added a Feedback request to un-deprecate the Text datatype.

<https://xojo.com/issue/65401>

2 Likes

Using Text it goes ok.

image

Off topic but looking at that made me realize why add always bothered me and why append made more sense intuitively to me than add…

The order you add things does not affect results fro addition and adding to list just means putting it anywhere on in the list not necessary at thee end …Append ONLY means add to the end.

Where is the beating a dead horse emoji when you need it! :wink:

-Karen

2 Likes

Oh yawn. Let him try TECO instead, he’ll love it.

I’ve added my voice to that report.

2 Likes

100% ok with this proposal.

1 Like

If you are asking them to have both Text and String then how would you even document for users when to use String and when Text ?

Problem here as Beatrix pointed out I think is that, in most cases this is not clear cut, and never can be. People will use Emoji more and more. Having both just makes it impossible for users to make informed choice on which to use.

3 Likes

Agreed. String should have capabilities to handle this.

4 Likes

MidB
String.MiddleBytes

THAT verbosity 450% more characters clutering the code

MsgBox to MessageBox, Ceil to Ceiling, ChrB to String.ChrByte, InStrB to String.IndexOfBytes, etc, etc.

Text was originally meant to be the replacement for String but that was rejected. So we have been adding to String features that Text has. TextArea has a Unicode mode. We could add something like that to String. If you would like to see that, make sure to file a feature request. We would do that rather than keep Text. Text won’t be removed for quite a long time since it’s part of the language, but we won’t be improving it. Improving String to handle what Text can do would make more sense.

9 Likes

Thanks for responding @Geoff_Perlman.

I find myself in a bind here as I have a product I thought was close to release but now find it has deep flaws due to String's mis-handling of characters. The “easiest” solution is to change every reference in my project for String to Text since that will solve the issues but then I will have a product using a deprecated language feature which feels wrong and risky.

Adding a bunch of extensions to String could work but I have no doubt that the performance will really suffer since they won’t be as fast as the native Text data type. One of this product’s selling features is its speed so I’m acutely sensitive to performance.

No offence intended but waiting on Xojo to implement a feature request doesn’t seem a viable option as there are no guarantees on turnaround time for implementation.

Why can’t Text and String exist beside each other? If the concern is that there is a risk of confusion to customers then I think that is the status quo. Those who need to manipulate bytes, are constrained by performance or know they will only be using common unicode characters can use String. For those who need 100% coverage of the entire language spectrum can use Text.