Lot of chatter in the blogosphere and forums about API 2.0. What do I think?
I think renaming the events was a mistake. Not because the philosophy behind the changes is wrong but because the IDE was not designed for it. In fact, I cannot think of any language that renamed events on their standard library classes. It just does not happen. Events are part of the core contract of the whole object hierarchy and all code developed in an OOP fashion relies on the stability of those events. In other languages they would release a new class.
The crux of the issue is the language and standard library are presented as a single entity in the IDE. It would be ridiculously awkward and painful if new projects started with AppV2 or WindowV2. Platform makers often just create entire new frameworks like WPF, UWP or WinForms. It is ridiculous, but it gives the developer choice. If I want to stick with my trustworthy but not entirely clear when it fires .Open() event I can just stick with Xojo Desktop v1.
When you create a project, it should ask you "API v1 or API v2" and that's it. The constructs of classes having events is the same regardless of their names so why does the IDE care which version you use? All it needs to know is which library to use for code completion. The fact that the choice is not possible or was never considered is the part that makes event renaming as delivered a rookie platform mistake.
I am not as upset as I could be as there was an even more asinine change that we luckily got reverted. The <beta> class that we all use every day had been changed in ways that are completely and utterly mind boggling. Who is driving the technical direction here?
If I sold you a plugin and it did not work and I told you that I implemented .Open() and your use of .Opening() broke my code you would understand. It makes sense. It is annoying and one questions how or why this is possible, but it makes sense.
What if I had said the reason your code does not work was a subtle change to the default constructor that made the entire object immutable? All I would get back from you is a puzzled look. Likely, you would ask for clarification about why I mentioned the default constructor.
That's right. Depending on the constructor you use, all properties silently changed their behavior and there is no way to know this in advance. If you have any existing code, you would reject using R2 on the premise that <beta> is completely and utterly borked. Funny, when they realized this, they changed the name of the class which is actually what should have been done in all cases of event, property, and method renaming.
Some of you will not use R2 because of event renaming but I promise you it could have been much worse. Worst part about all of this is R2 is actually a good release. Lots of things are fixed and improved and the database improvements without needing horrible prepared statements are much improved. However, there is also nothing shiny or stand out about the release. Subtle changes here and there give the appearance of a release with lots of effort, but it is mostly semantical nuances.
Array's moving from Append() to AddRow() is untenable for anyone with a computer science background. My thinking is in the future arrays can likely be used as a bindable data source and AddRow() represents the action occurring in the user interface. That's my imagination and hope for the product as I seek creative justification for these mostly pointless and subjective changes. All for the sake of a hypothetical future citizen developer who didn't buy and selected "did not understand the exact timing of Window open" on a marketing survey.
The struggle is I don't know why API 2.0 exists at all as a version milestone. It does not move the product forward in any meaningful way. If Apple had not released macOS Catalina, then this release would serve no function. I am concerned these changes were built in a vacuum not mapped to any real-world deliverable. The time to optimize is when you release new things like DateTime. Release Web 2.0 with API 2.0. Release Android with API 2.0. Release an enhanced desktop framework with new controls like a date picker and database binding with API 2.0. Allow API 2.0 to grow out of necessity and not as a milestone in and of itself.
The fact is if I use API 2.0 it won't improve my software and at the end of the day that is what creates Xojo renewals. Did my software just get a little bit better because I upgraded Xojo? Sadly, when it comes to R2, it does not.
For the future I recommend being less ambitious and evolve more areas of the product simultaneously so timespans between meaningful new additions is not so great. Produce more meaningful new additions. We are coming up on a second XDC with nothing new for the platform to encourage new developers to use it.