I thought Karen shared a very interesting observation:
“Rereading this made me realize an issue I have with API 2 that I had not consciously recognized.
Having the same methods names for different types of things means one has to look closer at code to understand it. It actually makes it harder (at least for me) to quickly understand someone else’s code (or eventually my own code if not is old enough)
In my mind for API 1 it was always Record -> Database Row -> list control or menu… UI related Just a method with an index (add Remove etc) -> array or other abstract list
So regardless of how the base item was named, It made it really easy (for me) to scan code and get a sense of what was going on quickly.
Now that things that are (in my view) significantly different in kind use the same method names, (for me) it makes it harder to pick up the meaning of a piece of code at a glance.”
I mostly find the opposite if I’m honest. I think it’s very helpful to abstract things as much as possible and I think API 2.0 does a good job at this most of the time. The one change I do find egregious is the replacement of .Append with .AddRow for arrays. I emailed Geoff before the public release of API 2.0 about my concerns but he was very insistent. He has his vision and he is sticking to it.
I wish they had used interfaces for API 2
That way the API’s would have to be consistently named - not by convention as it is now - but by design
And since the use of Interfaces establish an IsA relationship you could have added extends methods to any of the objects that used that interface
Lets take one example : List like things (single dimension arrays, listboxes, popup menus etc)
Since ANY object can implement one or more interfaces there’s no real downside to this
So listbox could implement the “ListInterface”, as could all those others.
And we could have written extension methods for anything that implemented Listinterface, could have written methods that took ListInterface items as their parameters etc
It would have facilitated more generic programming
Instead we have to write code that takes Listboxes as parameters, and overloads that take arrays, popup menus etc etc etc because NONE of them used an interface
I dont care for “AddRow” just as much as you dont - especially for arrays (blech !)
I would not have minded if they adopted a “List” API for those things that have some aspect of List behaviour - you can addItems (maybe thats a better name than addrow)
all water under the bridge at this point
they just need to fix the various bugs the new API 2 code has introduced
Here’s an excerpt from an email Geoff sent to me when I wrote to him complaining about the change to AddRow:
When we are explaining arrays to people who have never done any programming, the easiest way to do that is to compare an array to a single column of a spreadsheet where the data is in rows with numbers as the index. Explained that way, people instantly get it. Then when you move on to two-dimensional arrays, you simply explain that you’re adding columns. Again, they instantly get it. In that context, Rows make all the sense in the world. We learn visually first and foremost and as such it’s far easier for someone to think of an array as a column with rows or a set of columns with rows than it is to think of it as an abstract set of data.
He goes on (and I think I agree with him):
I personally think those who don’t like Array.AddRow will get over it. They mostly are just adjusting to something new where they see no benefit for themselves. And they are right: there is no direct benefit for them. The benefit is for those new to Xojo and new to programming. The indirect benefit however to existing users is that the easier it is for new people to learn Xojo, the more the community will grow.
I have to say I don’t think that is doing anyone learning to program any favors… If they do not understand the simple abstraction of an array, how could they code anything meaningful?
It also closes the mind to more than 2D arrays (at most!)…
Programing is all about abstraction IMO… Both in how to solve real world problems with code as well as in the coding itself. Not being able to understand a simple abstraction such as an array dos not bode well for there future in coding. Not having to even think it through is not doing them any favors IMO.
BTW When I first learned to code was before PCs existed, never mind spreadsheets! So that analogy would not have helped me!
I was one that suggested AddItem for arrays back during the API 2 fiasco.
Using Geoff’s spreadsheet analogy, you’re never adding a row of values (unless you’re importing/pasting). You add one item at a time. Further, you can’t actually add a “row” of values to an array at one time, which is what AddRow seems to infer! The only mechanisms in Xojo that lets you add an actual row of multiple column values are listboxes and database records. Which lends more weight to using a different command for arrays to prevent confusion.
I would be curious to know how the other engineers felt about the AddRow change. I can’t imagine they would ever talk about it though. I think this was something Geoff got in his bonnet. It’s his product after all. In any regard, I’ve been a earlier adopter of API 2.0 (using only API 2.0 since 2019 R2) and I’ve gotten used to it now.
Having just spent the last couple months converting all of my apps, and over 10,000 lines of code to API2.0, I know what a huge pain in the !@#$% it can be. If you have a project you’re looking to move to API2.0, give me a shout. US$50/hour. Code you have must compile, error free, as it is. But, I will correct all of the depreciations in your project. I’ve been working with RealBasic, REALStudio, Xojo since 1999.
I don’t see it this way. I moved several rather big projects to API 2.0 and none took me longer than maybe 2 hours. On the other hand, I am not scared by false deprecation warnings and update the rest of the code when I pass by.
Such horrendous conversion times are only plausible to me when you used 2019r2 which I skipped luckily, or when you want to remove every API 1 discouragement warning immediately.
Besides that, I enjoy API 2.0. Only ResizeTo killed me as I was so used to Redim to the count of an array where it now is the Ubound. But I guess I have memorized that for good now.
I think a lot of people see warnings as just as bad as errors and do try to remove them ASAP.
With the move to API 2 that means a LOT of warnings - I have one client project with about 30,000 deprecation warnings.
With that ne we have been slowly dealing with them as we work on new features & functions and update code in the same places were are working and have decided not to try & tackle them all at at once.
Perhaps I’m touching different areas of the framework in the work I do but many of my projects aren’t UI-heavy so I’ve not had too bad an experience with API 2.0 frankly. Honestly I’m glad it’s here because we might finally start seeing some unification between iOS and desktop…
