Geof posted about the virtues if new framework date class… arguing that it’s better to use despite being a bit more work because of how it handles time zones… and arguing once the new framework becomes standard it’s only one more line of code (you can get rid of the Using Clause) … In fact it could be one less than that by getting rid of the Dim of the DateInterval object
Dim d As New Date(2017,11,5,TimeZone.Current)
d = d + New DateInterval(0, 0, 0, 3)
Dim d As New Date (2017,11,5)
d.Hour = d.Hour + 3
But which is more accessible to the beginner or the non professional that just wants to create a solution quickly to a very specific need on their job? Which is more generally intuitive?
I’m not arguing against the need to deal with time zone or saying this particular thing is a big issue… but the overall nitpicking and formalisms make the new framework a lot less fun to use to use and less approachable than teh old. One needs an overall high level of computer science (not sure that is the right term) background knowledge to do simple things compared to the old framework…
Because of it’s rigorously formal nitpicking, the verbosity goes beyond namespaces when one writes code… and using it , at least for me, feels more mechanical than creative when compared to working with the old framework… and takes longer to accomplish the same thing (though familiarity could be a factor there)
I know more than few consider that a virtue , but if the new framework had been in place in RBV3 (when I came in), I wonder if I would have stayed with it.
Personally, I think the example Geoff gave is actually WORSE! It’s worse because the DateInterval constructor has 4 parameters and you can’t tell jack from just looking at the code. I mean, I can guess what they are (year, month, day, hour) but it’s not as readily apparent as the second example which has zero guessing (even though it could be incorrect).
To be very explicit to even novice Xojo developers I would do this:
dim di as new DateInterval
di.hours = 3
Absolutely zero issues with what DateInterval is. To me it’s a readability issue even if it’s not as compact.
I think there are a lot of good things in the new framework but this isn’t one of them, in my opinion. The new date class is stricter and thus safer in many aspects, but I wouldn’t call it easier to understand depending on how your write it. To make it easier to understand you do have to write more lines of code. Again, my opinion.
I think some of these issues will start to drop away as the new framework gets used more but I think your points are valid, Karen.
That (overloads) is why I miss the tips window, for those that remember it…
One solution with this UI (besides the IDE guessing which overlaid to display first) is using up/down arrows at the start of the bar to be able to cycle though the overloads. No overloads then Up-Down arrow.
Karen I’m a beginner and for my program I just need dates and not time. I’m using SQLDate with SQLite. Pretty easy. I don’t see SQLDate with Xojo.Core.Date. I guess I’ll have to learn how to deal with that in the future.
From what I read, sometime in the future there will be no Date and Xojo.Core.Date, and only the new one. So I’ll find soon how hard is for me to change my program.
[quote=357680:@Tim Parnell]I don’t think that will be an issue for quite some time.
Additionally, you could file a feature request for a SQLDate method on the new date class.[/quote]
Looks like this has been requested: Feedback 37521.
And it turns out there IS a relatively easy way to get SQLDate, SQLTime, and SQLDateTime using the ToText FormatStyle options.
[code]dim d as Xojo.Core.Date = Xojo.Core.Date.Now
dim t as text = d.ToText(Locale.None, Date.FormatStyles.SQL, Date.FormatStyles.SQL)[/code]
I will grant you that it’s not very discoverable and not as simple as the old framework methods. But given then information it would be easy enough to create your own extends methods for the Xojo.Core.Date class.