Geoff Perlman wrote a blog post https://blog.xojo.com/2017/11/04/get-better-dates-with-the-new-xojo-framework/ on how the new Xojo.Core.Date gives you a better date. Better in that it does a superior job of handling timezones.
I will concede the point that the new Xojo Date class is better at timezones. Timezones are icky and there are various areas of the world where they observe only partial increments of timezones. The existing, global framework simply can’t handle those geographical timezones properly. In addition to that, the global framework can get it wrong. So the new framework is inherently better with timezones: got it.
Where Geoff’s blog post goes sour, in my opinion, is when he talks about how the new Xojo Date and DateInterval classes cause more code but then goes on to show how it can made shorter. I think his shortened example is indicative of the overall problem with new framework.
He starts with this example (note I am not implementing the Using keyword on purpose):
Dim di As New Xojo.Core.DateInterval
di.Hours = 3
d = d + di
The results is a message dialog displaying: 2017-11-05 02:00:00. This is what the old Date.SQLDateTime method returned and what many developers need for database SQL operations.
He then goes on to show that this code can be reduced to:
Dim di As New DateInterval(0, 0, 0, 3)
d = d + di
Sure, it’s reduced, but now we’re passing parameters into the DateInterval constructor that we have to just know what they are. Granted, it’s not hard to figure it out but when I’m reading code I don’t want to have to ‘figure it out’. Whereas the first example was pretty explicit (add three hours) now I have to parse the number of parameters to figure out it’s three hours and not three days or three months or three seconds. If when writing code I accidentally leave out a 0 it wouldn’t be immediately obvious that I’m not adding three hours but three days. Ambiguity is never a good thing and I can’t tell you how many errors I’ve found in methods that have multiple parameters with default values because someone (usually me) missed a parameter.
I’d also argue that the documentation for Xojo.Core.Date is using, at worst, wrong example code or, at best incomplete documentation. Using the variations of ToText results in some counterintuitive results. If you use Xojo.core.Locale.Current (as all of the Xojo examples do), you get results based on YOUR system settings. Really what you should be using is Xojo.core.Locale.Raw. Below is a table that shows the differences for the following line of code when run on my macOS machine:
X = Xojo.core.Locale.CurrentXojo.core.Date.FormatStyles.Full 2017-11-05
|Xojo.core.Date.FormatStyles.Long||Sunday, November 5, 2017|
|Xojo.core.Date.FormatStyles.Medium||Nov 5, 2017|
So given these results it’s impossible in the new framework to get just SQLDate as the FormatStyles.None is ignored. <feedback://showreport?report_id=50242> Until this fixed, to do this on your own you would have to split the Text on the space and use the first half of it.
The only reason why anyone should ever use Xojo.Core.Locale.Current is to display the date/time to a user. Xojo.Core.Locale.Raw should be used for everything else. The distinction between these variations is confusing even to experienced Xojo users so I can only imagine the frustration from newcomers.
Ultimately, the New Xojo framework is not very discoverable and this leads to frustration. While writing this article, to figure out the parameters in the Xojo.Core.Date.ToText function, I had to look in the freaking documentation. Yes, there is the tips area but it’s not very helpful while you’re typing. To see what the tip is you have to stop and hover your mouse over the method. And that only works if it’s not an overloaded method.
This leads to some users complaining that Xojo isn’t as much ‘fun’. At first I pooh-poohed the idea but the more I think about it, it’s true. The new Xojo framework is verbose and hard to discover and therefore not as much fun. I work in this language every day and while calling it ‘fun’ might be a bit of a stretch I can tell you that using the new framework isn’t fun. The two client iOS projects I’ve done in Xojo have been painful for a number of reasons and not being fun is a valid but minor point. I don’t find the documentation to be nearly as easy to read and discover related topics, and frankly the new framework seems to make things harder than necessary. Certainly there is a ‘this is the way I like it’ factor you’d get from someone with nearly twenty years using a language but I do feel that the new framework is needlessly nit-picky.
My first blog post https://www.bkeeneybriefs.com/2014/12/xojo-core-date/ on the Xojo.Core.Date class was in December of 2014. It’s nearly three years later and we’re still dealing with bugs and idiosyncrasies and it’s not widely used despite clearly being ‘better’. It’s no wonder why people don’t really want to use the new framework and I wonder if any parts of the IDE are using the new framework.
What are your thoughts on the Xojo framework?