I think I am starting to put my finger on the misunderstanding here. Bear with me on this as it is not fully formed but it feels like perhaps Xojo believes the “Citizen Developer” well never have been exposed to any other language prior to Xojo.
On the contrary in my opinion they find Xojo because they find other languages so unsuitable or complex. So Xojo’s niche and appeal is being easier than the others.
It also hints a bit at “not invented here syndrome” when dominant ideas in other tools are discarded by merit of being in those products.
To put it another way and follow Paulo’s auto analogy: Xojo does not have to re-invent the wheel; Simply make the tires last a little bit longer.
In the short term no - both classic & new frameworks will be present as they are today
Longer term the new framework will grow and we expect that it will grow enough that you opt to use it for an increasing amount of work and come to rely on the classic framework less and less
I suppose if we hand’t used “STRING” for the lat 15 years then “STRING” would make sense.
But we have - and we cant have 2 types with the same name in the global name space and have it work.
So simply because we could NOT use STRING we had to pick a different name.
TEXT makes sense because it is textual data - meant to be read and viewed by humans reading it.
The semantics of the TYPE - not the language
What I mean is that if we ripped the guys ot of String and replaced it we may NOT be able to duplicate the existing API’s and guarantees - such as they are - using new underpinnings.
And if we cant do that but changed the implementation anyway, as had been suggested more than once, we’d have changed everyones app behaviour because the way the type behaved changed
And that would have been a worse disaster
So we tread carefully if we think about doing that.
We have done a bunch of work in various areas and have had to reimplement bugs JUST to not break existing code because someone may be depending on those bugs.
It seems silly to say “lets do all this new work and make things better - oh but we have to implement this bug and that bug and …”
No ?
Trust me you’re not the only one who is disappointed the new framework hasn’t moved ahead as rapidly as we originally planned.
Best laid plans and all.
I have to say I have personal reservations about TotalSeconds only because there already IS a SecondsFrom1970 on the new date.
Not sure we want 2 “seconds” type accessors & mutators (getter / setter) on a date - esp since they are NOT based on the same epoch.
I think the SQLxxxxx accessors / mutators have been requested already
No. It’s not about that. Xojo is filled with technology we did not invent. We don’t do things differently for the sake of being different. We do it differently when we feel there’s a better way. That’s why I founded this company in the first place.
String was the wrong word to use from the very beginning. I spent 4 years teaching programming in Silicon Valley. I saw first hand what people found to be intuitive and what they didn’t. At first, I taught the classes the way I had seen them taught by my predecessor. I would make a lot of analogies and such then at some point, I would see the light bulb go on over my student’s heads.
After this happened enough times, I realized why. The light bulb always went on when I had shown them that some new idea was the same or nearly the same as something they already knew about. It occurred to me that brain is associative. We associate new information with something we already know. So I sat down and recreated all of the classes from scratch. Instead of teaching students all the various parts of the language, I would instead teach them how to solve problems using the language. We would start each lesson with a problem they could all identify with and then I would teach them all the various parts of the language that they needed to understand to solve that problem. At the beginning of class I would ask them about other tools and languages they had used so that if I could make a comparison, I would.
Once I made this change, I frequently had students come up to me at the end of class and tell me that it was the best class they had ever taken in any subject. I had had a simple epiphany that turned out to make learning far more effective than any system that I had ever learned from or my students for that matter. I’ve since come to realize that most people who teach aren’t nearly as effective as they could be but that’s an entirely different discussion.
At Xojo we only change things when doing so is going to a reasonable improvement. I could care less who came up with an idea. I just want the best ideas. String was never a good idea. The person that chose it was clearly an engineer who was used to working with computers at a low level and made little consideration for the higher level users would be not be like him. I don’t blame him for that. It would have been an amazing degree of foresight had he thought to give it a more appropriate name. However, just because others have continued to use that poorly chosen label doesn’t mean we have to as well. People used to string will quickly realize that Text is the same thing. Those new to programming will see integer and recognize it because they know what an integer is. They will see Text and recognize it because they know what text is.
Making Xojo as intuitive as we can has always been an important goal. The change from String to Text is one simple example. I know it’s different. I know it will take some getting used to for some of you. There have been and there will be many other changes that have been and will take getting used to but that’s the nature of progress: it requires change.
I think many Xojo-ers are cool with the change. I think we get hung up because Desktop and Web use Strings and iOS uses Text. That makes writing cross-platform code harder.
[quote=359416:@Hal Gumbert]I should have said a modifiable SecondsFrom1970.
[/quote]
Ah
I would expect this would behave like Date + DateInterval where the original is unmodified and a new immutable instance is returned
At first glance that seems plausible
[quote=359416:@Hal Gumbert]
I take it that taking Web and Desktop from String to Text is a huge deal? Not just a find and replace? Sorta kidding…[/quote]
For us ?
Very much so simply because TEXT is not a 1:1 swap with STRING
String has long had this dual “bag of bytes” or “textual data” behaviour - TEXT does not
And that makes it unlikely we’d just modify the classic framework in this fashion
If we did this, the next time you compiled a version of your app, you’d have a lot of subtle behaviour changes.
Hence why so far we’ve made it so things can interoperate and you can slowly change over as you see fit.
I expect we’ll do much the same with desktop controls as well - so you don’t have to make a wholesale change over in a hurry.
Web, as you know, is going to have a new framework and I have to admit that while Greg has been working on it I haven’t been tracking things closely. He’d have to comment on the direction there.
I think you have hit the nail on the head. If we had delivered the entire new framework for all platforms simultaneously, there would have been some grumbling from some about getting used to all that is new but that would disappear quickly. The problem is, at the moment you are stuck between the two. You can’t entirely switch so you have to go back and forth which is frustrating.
Projects that took longer than we expected (64 bit) and others that suddenly appeared due to changes outside of our control conspired to delay our progress on the new framework. Now that those are mostly behind us, you can expect to see some rapid movement on the new framework APIs in 2018.
My main “bellyache” with text is that my app mostly does “text crunching” with all sorts of bad data. Really screwed up data coming from mail clients.
In the old framework my code parses the data until the data is nice and clean. In the new framework my data can’t be text because the data can have all sorts of encoding problems. But I can’t use memoryblock because I need different text functions for the memoryblock. This type of “string data” doesn’t fit into the nice world that Xojo wants to make with memoryblock for data and text for text (that sounds totally stupid). How do I deal with my “string data” in the new framework?
I was in that same boat on a project. The Xojo.Net.HTTPSocket did not return real Text that could be encoded but I had no mechanism to parse it. I believe I converted the Xojo.Core.MemoryBlock to MemoryBlock and then to String (implicitly) in order to perform my necessary edits.
At the moment I’m not yet looking for concrete solutions. Just wanted to remind the Xojo persons that their world of memoryblocks vs. text won’t work for everyone. Memoryblocks or the mutable variations need more work.
As interesting as the last few hours have been in that thread and they have been interesting this in my opinion is the real problem:[quote=359420:@Geoff Perlman]Projects that took longer than we expected (64 bit) and others that suddenly appeared due to changes outside of our control conspired to delay our progress on the new framework. Now that those are mostly behind us, you can expect to see some rapid movement on the new framework APIs in 2018.[/quote]
It is always the same excuse, sometimes comprehensible, but often not. Here is an example for the latter:
Exactly. To excuse this with the troubles of 64-bit suddenly getting urgent is ridiculous:
Everybody in the business even an amateur like me knew at that time this would happen sooner than later. Xojo Inc just misjudged the situation and wasn’t prepared. And now again the same naivety:
It might work after all the dissatisfaction which has been “unloaded” in this forum. But then another important promise will be broken, on improving the iOS or the Web framework, or on something else like for example the ability to write plugins in Xojo just pick something which is important to you (a little portion of sarcasm must be allowed).
I stand by my statement made in the other thread, that this is a management problem. In the seven years using Xojo nothing has changed in this regard. And there are no statements made in this thread which show that Xojo Inc has learned something out of this on-going promise-delay-cycle.
String is a superclass of text, which is “a string of characters”.
Confusion comes in with the .text property which is VERY intuitive. Changing that to “value” is counterintuitive as “value” implies “numeric value” to both newcomers and experienced programmers.
For me it is one of those things where Xojo shoots its own foot without good reason.
