That, and it still serves a purpose if used correctly. The new MemoryBlock comes close, but still isn’t as convenient as String to hold a bucket of bytes.
Or maybe it would be once I switch to the new framework more, idk.
Having said that, I get why Xojo would like to move away from String. It’s a cross between a MemoryBlock and Text and we are ultimately better served by using one of those instead. If they kept String, users (especially ones that have been around for a while) would keep using it and keep facing the same issues they are trying to do away with, usually centered around a misunderstanding of TextEncoding and how it applies to String and why it’s meaningless with Text.
If they introduced Operator_Add on the new MemoryBlock so we could do mb1 = mb1 + mb2, I’d miss String less.
Feedback report for easy conversion of String to the new MemoryBlock:
String is a source of confusion not only for newbies but experienced people as well.
We get numerous bug reports about “this is broken” only to find that somewhere along the line a string with an encoding has been concatenated with one that has a nil encoding.
Text avoids this.
We’re trying to make it still easy to write code and NOT have these kinds of inadvertent errors or having to learn the secret handshakes just to use the language.
There are a lot of little gotcha’s that bite everyone from time to time that we’re trying to remove or at least make obvious.
Things like having to know the right order to add years months days hour minutes & seconds to a Date to actually advance to some other date without getting really weird results.
Or FolderItem.ModificationDate.TotalSeconds = 
Regarding dependencies and moving forward:
I mentioned in my blog article as well as the deleted thread that a Classic API support module would be a good compromise.
Put all the code you dont want in the new framework permanently in there as extension methods. Auto add it to projects being converted from previous version and provide checkbox for new projects Support Classic API?
Definitely use Xojo.Net.HTTPSocket over the classic HTTP sockets. They work very similarly, but the new socket uses system calls so it be more compatible, more secure, and better maintained.
Xojo.Data.GenerateJSON is dramatically faster, but has no support for formatting like JSONItem does.
Xojo.Core.Date is better in many ways, but is inconvenient in very many regards. It also handles timezones incorrectly on Windows, so at this time I recommend avoiding it. The fact that FromText can’t accept a timezone at all is atrocious.
The rest is really take it or leave it.
It really needs more than a timezone do “do the right thing” which is why fromtext takes a locale
If I have a SQL timestamp with time zone, I need to use FromText to parse it incorrectly first, manually parse the time zone, then use the “long” constructor to build a second date with the original’s values + the time zone object. If FromText would respect the timezone or at least allow me to specify which timezone, or if I could change the timezone, those would all be solutions.
Thats basically what we’re doing by putting the “ConvertTo” methods on various Classic framework items
But that doesn’t achieve others stated goal of “autoconversion” since you cant create an extension that is operator_convert
WE’re doing about the best we can without inserting dependencies we cant get rid of
If the Classic Framework will be here for 5, 10, or more years does that mean that only iOS and new targets will be 100% New Framework while Desktop and Web will be Mixed Frameworks long term?
There’s no intention of implementing a “Classic framework for iOS” AFAIK.
I say “implementing” because there would be no “port” as iOS doesn’t have support for many of the OS API’s used in the classic framework. And there may not be a way to implement the same semantics as what currently exists in the classic framework.
And that is a big issue.
IF we just replaced the existing HTTPSocket with Xojo.Net.HTTPSocket there would be several behaviour changes - never mind that you couldn’t use it synchronously. And that sort of thing we try to avoid because it leads to surprising new bugs/issues in existing code that “hasn’t changed”.
There’s calculating deltas from dates, encodings for text input/output and and memory blocks are now specifically using binary data. Is there anything else?
It’s only meaningful if you’ve already learned what it is in another programming language. And even there it wasn’t intuitive. I’d much rather have an intuitively named type then continue with one that makes no sense. You guys are used to it because you learned it elsewhere. Those new to programming see if and can’t understand why on Earth it would be called String.
I am finding it difficult to locate any “mainstream” language that uses “TEXT” as a datatype in lieu of “STRING”…
Even Apples own SWIFT uses STRING, and this is probably on of the NEWEST languages around.
I totally disagree with this statement. Semantics are what the language developer wants them to be…
For example, I have a framework that I wrote (for Swift, so don’t shoot me, just proving a point)… This framework includes a full SQLite syntax, String library and Math Library that encapsulate functions of Swift and ObjC into a lexical that matchs that of “other programming languages I know”
While I have never written or designed a COMPILER, I have written a number of Interpeters, and a Transpiler.
Thanks Norm. Will Desktop and Web move to 100% new framework?
[quote=359391:@Dave S]I am finding it difficult to locate any “mainstream” language that uses “TEXT” as a datatype in lieu of “STRING”…
Even Apples own SWIFT uses STRING, and this is probably on of the NEWEST languages around.[/quote]
“Because it’s what everyone else is doing” is not a good enough reason alone to do anything. Anyone who has programmed in a language that uses String will learn in 2 seconds that Text is the equivalent and they will get it. The brain is associative and that association works. String to mean text OTOH is not intuitive at all.
It would be a bit interesting to see what Xojo team would publish as update and/or new features in coming version and/or versions.
I think this become irrelevant discussion if we are looking from part of development, even of Xojo development.
At the end of this my post for tonight, I think that Mr @Geoff Perlman should officially and clear announce what we should expect that will come this days, in closer future and in future from Xojo and then we can put hands on it, to talk and make discussion regarding to improvements otherwise this can go in wrong direction.
All the best to Xojo team and I wish that they again will stand up and make Xojo more powerful then what it’s now.
Guys your close to make one more time greater thing and it’s up to you dear Xojo team only.
In that name, keep walking, Cheers! and Get ready
Salute!
No, you’re not alone.
+1
@Geoff Perlman let me disagree, the fact is not whether others are doing is correct, but rather whether my clients are satisfied with me.
I’ll tell you a quick case, the Renault made a car in Brazil that was called LOGAN, this was to be a cheaper car but not wanted to please Design, had good mechanics, but since it was very different from the current standard, it was ugly and too square, people simply did not buy the car, Renault surrendered and redesigned the car, even though it had raised the cost people started to buy and the project was feasible to continue.
What I mean is that if the community (Customers) is bothered with TEXT and STRING type changes and more some others, I think it would be wise to pay more attention so this is not a new LOGAN.
I hope not to be misunderstood because my intention is only to help, tanks for your attention !