Nothing has changed in 10 years

https://web.archive.org/web/20120512060057/http://www.bkeeneybriefs.com/2012/04/open-letter-to-rs

Wow. That was written 10 years ago and could have been written today.

Nothing has changed with Xojo.

Bob wrote this nearly 10 years ago

Ouch !

Can you recall us what is the Bob’s situation today ?

Still using Xojo, although on a much smaller scale I beleive

I’ll jump in. I’m still using Xojo on a daily basis for my new employer. However, we also have long term plans to move a substantial amount of pure Xojo code to Go so I’m getting up to speed with that language. Xojo will be used for many years as the front end but by moving much of the processing to Go I think we’ll be better served if Xojo goes belly up or moves in a different direction than what we want to go.

I’m no longer in Kansas City and roaming the US while living in an RV. Currently near Raleigh, NC if anyone is in the area and wants to get together for a meal, drinks, or both.

3 Likes

I guess no one can they they’re not in Kansas anymore, anymore.

1 Like

Yes, they all migrated to Kansas City, Missouri…

Well, I did live on the Kansas side…

That what people usually understand. The other side of the river is not so well know (KCMO).

Even the song talk about the Kansas State City.

I promise we wont hold that against you :stuck_out_tongue:

Pft! I’ve heard that before. :slight_smile:

The “new framework”, if that’s the one that resulted in all the “Xojo.Core.xxx” stuff, was a colossal waste of time. I never understood what it was supposed to accomplish.

The Xojo IDE is a masterpiece of form over function when compared with RS. They were finally getting the RS bugs under control (yes, it did crash too frequently) just when they dumped it for shiny “modern-looking” (but far less usable) Xojo. “Better is the enemy of good”, in the immortal words of Voltaire.

1 Like
  1. isolate Xojo items from yours (so when Xojo adds a new control , class, method its possible to disambiguate it if needed by simply using the fully qualified names) If you happened to be around when “StaticText” was renamed “Label” and it suddenly collided with a LOT of user instances named “label” you’d understand why this would be useful
    ANY time Xojo now adds a new control, method, class etc because everything is in a more or less global namespace there is the risk they add something that now conflicts with your code

  2. by doing #1 make it possible to dead strip unused code better (since its not all one giant global namespace the compiler can do this)

  3. make it possible to actually mix and match “classic code” with “new code” so you could slowly move over as the new code got more & more capabilities

there were other benefit but these were the big ones

that plans didnt pan out as intended wasnt indicative of it being a bad plan

1 Like

It isn’t Xojo’s job to pre-emptively deal with user-caused problems, especially when they are easily fixed with a suffix.

It’s their job to be efficient and easy to use for all - so if you used Label then rename it to LabelNP, do a search&replace, and you are done - no need to inconvenience EVERYONE for it.

So it definitely wasn’t worth the hassle it caused.

EVERY change has a cost - the cost and inconvenience far out-weighed any presumed benefit, and it was a really bad decision.

You misunderstand
For years Statictext was the correct control name
Then Xojo (real at the time) renamed their control to LABEL

And THAT caused the problem

Not users

The point was Xojo could avoid XOJO changes causing those issues for users

Actually, it’s YOU who misunderstands.

When Xojo introduced LABEL they inconvenienced SOME users (who could fix the problem quite easily anyway)

Their “solution” was to inconvenience ALL users and make the language much worse.

No wonder they had to walk the changes back.

If a change is really beneficial then Xojo should NOT be held back by what some users are doing - basically users having their own StaticText called LABEL is an admission that the change is indeed beneficial.

What Xojo should NEVER do is make the situation worse for ALL users - that is a REALLY bad idea.

StaticText was always an odd name
By renaming it in a global namespace they had no recourse BUT to inconvenience everyone
OR just NOT do it

We know which way they chose to go :stuck_out_tongue:
They never did walk that change back though

What opportunity they did miss was there is/was a way to NOT clobber everyones existing code & still rename the base control

Thats exactly what namespaces are for

I probably expressed myself badly.

I have no problem with the change from StaticText to Label, even if it inconveniences some users.

I have a BIG problem with the “Xojo.Core.xxx” - the attraction of Xojo in large part is its simplicity and readability.

I started using Xojo right around the time they made that change, and while it did cause some issues with changing code… THOSE changes I really didn’t mind, because to me “StaticText” was a worse control name than “Label”… .but the API 2 changes were way worse.

Also wasn’t there another control that had its name changed at the same time as “StaticText”?

EditField to TextArea