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)
MsgBox(d.ToText)
Compared to:
Dim d As New Date (2017,11,5)
d.Hour = d.Hour + 3
MsgBox(Str(d))
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.
How would this work when the constructor is overloaded? The IDE may not be able to guess which constructor you are intending on using until you’ve added a few parameters.
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.
It is - because its NOT quite as simple to implement as you guys might thing it is
It was requested by an ex-engineer who had tried to do make the IDE do this AFAIK
I’ve investigated it periodically and its quite difficult to do and would probably make autocomplete slower
What going to happen with my extensive use of d.SQLDate in my code when Date Classic is actually removed? Will the new framework somehow accommodate such code?
Alternatively, will I just be able to roll my own Date class extension SQLDate when Date Classic disappears, and just leave d.SQLDate entries alone?
[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.
A variation of the 62 case is in the VBA editor since I do VBA (2000 or so). This really makes a difference for functions that have more than 3 or more parameters. A pity.
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.