XDC 2019 API 2.0 session discussion

Just watched this at https://www.youtube.com/watch?v=rPjbH4_sARs&t=216s. Nice of Xojo to publish this without cost :slight_smile:

I’m intrigued that you can now address folderitems using child as a 0 based array and how that will work with the current child as a named file in the folder?

Methods are differentiated by their parameters. The old child takes a String, the new one takes an Integer. There is no ambiguity there.

That is what we already have now(FolderItem.Item), but 1 based Integer.

It was 0-based, but that one returned the .Parent (I think, not sure, and nobody cares now).

Probably a good idea to do that with .Child, and 0-Based (please, 0-base all/everything, so nobody will ever ask itself and search in the documentation about 0-based or 1-based…).

I’m going from memory here but isn’t it .Child in API 2.0 and .Item in the classic framework?

That is what I wrote above (“That is what we already have now”).

Edit: and this does not means anything else: API 2.0 is far better IMHO.

Yes
Since overloaded methods are distinguished by their parameters this could have been named “child” with an integer param all along - it just wasnt

I added some comments to the video: https://www.youtube.com/watch?v=rPjbH4_sARs&t=216s

Also, I hope it’s a Typo: String.EndWith. Should be “EndsWith”. Can anyone confirm that this is the case?

Just watched it…

One thing which could be an issue for a few years is needing to use different xojo versions depending on platform or OS version…

While ideally it would never happen, in the real world sometime a new method works well on one platform or OS version but is problematic on another (and this may increase with more use of OS APIs under the hood - particularly on the Mac with its rapidAPI changes) so we may find we need to keep code compatible with classic code or easily go back to the old way so we can move between IDE versions…

In those cases we may want to make sure we are NOT using API 2.0 calls to maintain backward compatibility, I wonder if that could be an analyze option - indicating lines out where API 2.0 IS being used and maybe mentioning the old method.

Also for analyze project for both this and deprecated items, would it be possible to have a a double click (or contextual menu choice) on the item take us to the relevant doc page in the help?

Though I never embraced Xojo Core in my projects, one of the sentiments that I had during the conference was API 2.0 would be the way forward while original framework / core framework could be used, it would not be updated unless there was a serious bug. Also, once you move to later releases of Xojo, it wont be possible to bring your project back to earlier versions.

Again, it makes sense, we just have to embrace the change like we do with Apple products.

[quote=435992:@Rich Hatfield]Though I never embraced Xojo Core in my projects, one of the sentiments that I had during the conference was API 2.0 would be the way forward while original framework / core framework could be used, it would not be updated unless there was a serious bug. Also, once you move to later releases of Xojo, it wont be possible to bring your project back to earlier versions.

Again, it makes sense, we just have to embrace the change like we do with Apple products.[/quote]

For the long run yes… but the transition period is the issue (though less so than with Xojo Core), because of the time it takes for new things to become stable with good performance across all the relevant platforms/OS versions supported.

Over the years I have learned to be weary of adopting newly implemented Xojo features because of potential bugs (when there is a significant amount of new code, there will likely will be some bugs initially that were missed) as well as performance issues (which may be platform specific) …

It often takes several releases before things settle down.

I usually like to use the current version if possible, but until I know for sure the new features are OK, keeping code compatible with prior versions, even with new code, IMO is a good idea. Been burnt by not doing that in the past!

  • Karen

Yes and understood. However, you will need to be weary about using newest version with current projects if your plan is to go back to prior versions. I believe there will be no undo once you go with the latest. Only way I can see around this is maintain 2 code bases for the same product.

That question was asked in the video… At least initially going forward, from what was said in the video, that will not be the case.

  • Karen

[quote=435997:@Karen Atkocius]That question was asked in the video… At least initially going forward, from what was said in the video, that will not be the case.

  • Karen[/quote]

Maybe I am remembering it differently, but I believe that was a reference between converting your code from the old framework / core to API 2.0. That did not reference saving projects in the new version of xojo and then being able to open them up in prior versions.

It’s in there…IIRC Paul said source code is source code so the old IDE will open it, but would not understand the new stuff.

  • Karen

you need to watch Web Framework 2.0 presentation from greg. around 17:15 he talks about project transitions where he discusses one way operations and that your project could have code updated to the new data types in api 2.0 once you agree to convert your project.

this is why once you convert your project, it will probably break on prior versions.

web projects moving from web 1.0 to web 2.0 are a whole different thing from moving an existing project using the classic framework to a new one that has an IDE that supports API 2.0

because of the wholesale rewrite of web 2.0 the transition from a web 1.0 to web 2.0 is one way

but a classic desktop app being opened wont have that need to “transition”

right, so if i have a web project that is converted to the new framework then i wouldn’t be able to go back to previous xojo version using the converted project. the only way to go back would be to fork the main code and maintain two projects.

sure but that will only apply to web projects because older IDE’s wont understand web 2.0 at all
most other project will be unaffected by this

API 2.0 wont be forced - but if you DO use those functions you could still open the project in an older IDE
Just the API 2.0 functions wont be available

at least thats what I would expect

What made me smile: First we learn about Dim becoming Var in API 2.0. Then the Database using Exceptions. And look at the example code for that in API 2.0 - all is using the ‚old’ Dim :wink:
Just before that they want to have all example code embracing API 2.0.
Not an issue - it just made me smile :slight_smile: