What was the reasoning behind the new join?

Why did we go from

x = y.join(z)


x = string.fromarray(y, z) ?

And if they like typing so much, why keep split?

Makes the languaje look more modern?

Users pay for releases with changes?

Long keywords and a verbose languaje is the way of xojo to be in the “low code” trend?

who knows :man_shrugging:t2:

Don’t you know you sdo not have to type so many characters ?

Tip: type the firsts characters an press the Tab key…

Also: who define, at Xojo, the language ?

The Language is defined by the developers and the head of development. Why there couldn’t be both: I have no Idea. Why to change between is not logical as is. While they modernized their frameworks they had a few Ideas nobody knows what’s behind. Deprecating functionality which works without compromises is never a good idea. You should ask Geoff Perlman for it. To me I guess he will not answer this question, at least I could not ask in Xojo Forum.

I asked the same question during API 2’s development and I was looked at as if I had a three heads. I can’t figure out why they think String.FromArray is better than just Array.Join.

How different methods of String handle source string and parameters is mildly incoherent. I don‘t get the idea behind.

The reason is quite simple actually.

Geoffs “EGO”

He realized that he needed a “hook” to attract more users, especially “newbies”, and figured that Xojo needed to be modernized. To him that mean changing the syntax simply for the sake of change. And if the required syntax was more verbose than he thought that newbies would be fooled into believing it was a superior programming language (which of course the rest of us now know to not be true).

I’ve been in this field for 40+ years, and personally find nothing wrong with the “BASIC” like syntax that is in use… A competent developer can arrive at superior results regardless of the syntax (assuming of course the syntax exposes enough functionality)

I’ve written a framework library for Swift that actually uses more familiar syntax to encapsulate some of Swifts more “interesting” syntax. And I based it 100% of how the Xojo API1.0 would have stated it.

For example : JOIN comes in two flavors

x = y.join(z)
x = join(y,z)

So in my opinion, those changes from API1 to API2 that were nothing more than syntax and name changes were a total waste of effort on the part of Xojo, and provided ZERO added benefit to the product


I would love to hear their rationale for deprecating join and not deprecating split.

Only Xojo Inc can tell.

but it was fun because they had to re-write the documentation :wink: - at least that was the plan I suppose. And let’s not forget that 2/3 of the posts containing code on TOF are now (soon) obsolete.
I wish they were consistent and hello2@xojo.com would be an alias to hello@xojo.com.

I would whish that consistently Management for the docs for all versions to give devs possible ways to find all needed solutions

1 Like

Both still exist
Autocomplete just wont show you the old ones
Unless you manually add to the preferences

<key>Show Deprecated Autocomplete Items</key>

Like in “low code” :wink:

where did u put the extra info??? I mean where is the preference file?

Wasn’t API 2.0 supposed to make things more consistent?

On macOS its in ~/Library/Preferences/com.xojo.xojo
Open it with BBEdit or TextEdit and put it just about anywhere in the plist

thanks… just did it…

Unfortunately the consistency goal wasn’t even achieved, as predicted. A language will never be perfect. Just today I was trying to figure out why I couldn’t find the IsVisible property on a FolderItem. Directory became IsFolder. Alias became IsAlias. Why didn’t Visible become IsVisible? We still have Locked and not IsLocked too.

Same inconsistency as before… But now “more modern” :rofl: :rofl:

1 Like

No later than yesterday, I created a blank project with Xojo 2015 (on an i5) and moved it to my m1 MacBook Pro, then use it (populates) with 2021r2.1.

The problem was “moved” from how do I do that in API2 to {sh*t, I forgot how to do that in API1}…
So no help from auto complete until minutes ago when Christian send me how to do that in API1…
I was able to get the new API2 syntax (and I tested that with Xojo 2022r3: the AutoComplete help shows how to go from API1 to API2).

The question ?
How do I Insert string in a TextArea (at first In sert Text at Position 0, then elsewhere in the text).

Append Text was easy: I found it in the docs.

Talking about the doc… Who wrote it ?

At last, as David nearly said:
API 2 was what it was AND was also a waste of time for the Xojo engineers to do. Time lost to remove bugs and/or add missing functions compared to competing products…