TimeStamp deprecation and related frameworks (GLORP, Grease, Magritte, Seaside...)
I started the migration of my apps to Pharo 4 and during the transition the only thing that seems to cause issues are the references to the TimeStamp class (particularly, its instantiators, like #now, #current, etc.). However, there are frameworks like GLORP that use TimeStamp extensively. E.g. GLORP's <Dialect class>>#timeStampClass> returns TimeStamp, and so does some other methods like Grease's #magritteTimeStampClass. What should be the proper way to update the references? Simply changing the returned class of #timeStampClass-like methods from TimeStamp to DateAndTime? In the case of GLORP, which I'm updating too, TimeStamp use is more extended, because it's also a datatype used to map table columns, but using no timezone offset. I guess if we move to DateAndTime we should preserve that behavior in order to not break anything. What are your suggestions? Esteban A. Maringolo ps: I'm so tempted to fork from the GLORP package, rename as something else (PLORM?) and refactor it mercilessly.
On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I started the migration of my apps to Pharo 4 and during the transition the only thing that seems to cause issues are the references to the TimeStamp class (particularly, its instantiators, like #now, #current, etc.).
However, there are frameworks like GLORP that use TimeStamp extensively.
E.g. GLORP's <Dialect class>>#timeStampClass> returns TimeStamp, and so does some other methods like Grease's #magritteTimeStampClass.
What should be the proper way to update the references? Simply changing the returned class of #timeStampClass-like methods from TimeStamp to DateAndTime?
Yes. TimeStamp is basically an empty subclass of DateAndTime. The only thing it ever did was use another print representation. All that is still available in DateAndTime. You won't lose any functionality by switching. I even think that DateAndTime is more ANSI, if you care about such a thing.
In the case of GLORP, which I'm updating too, TimeStamp use is more extended, because it's also a datatype used to map table columns, but using no timezone offset. I guess if we move to DateAndTime we should preserve that behavior in order to not break anything.
I don't understand this last point, could you elaborate ? As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do.
What are your suggestions?
Esteban A. Maringolo
ps: I'm so tempted to fork from the GLORP package, rename as something else (PLORM?) and refactor it mercilessly.
That is something else ;-)
2015-04-29 12:49 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo@gmail.com> wrote: In the case of GLORP, which I'm updating too, TimeStamp use is more extended, because it's also a datatype used to map table columns, but using no timezone offset. I guess if we move to DateAndTime we should preserve that behavior in order to not break anything.
I don't understand this last point, could you elaborate ?
As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do.
Me neither. But I simply don't wan't to break anything. :)
ps: I'm so tempted to fork from the GLORP package, rename as something else (PLORM?) and refactor it mercilessly. That is something else ;-)
:)
I uploaded a new development version (1.12) to the ConfigurationOfGlorp available at DBXTalk/Configurations repo that replaces the references to TimeStamp by DateAndTime. If anybody is willing to test it we can bless it as #stable. I used it and ran my tests against it and it caused no side effects so far. Esteban A. Maringolo 2015-04-29 15:36 GMT-03:00 Esteban A. Maringolo <emaringolo@gmail.com>:
2015-04-29 12:49 GMT-03:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 29 Apr 2015, at 17:39, Esteban A. Maringolo <emaringolo@gmail.com> wrote: In the case of GLORP, which I'm updating too, TimeStamp use is more extended, because it's also a datatype used to map table columns, but using no timezone offset. I guess if we move to DateAndTime we should preserve that behavior in order to not break anything.
I don't understand this last point, could you elaborate ?
As far as I see it, there is nothing TimeStamp did that DateAndTime cannot do.
Me neither. But I simply don't wan't to break anything. :)
ps: I'm so tempted to fork from the GLORP package, rename as something else (PLORM?) and refactor it mercilessly. That is something else ;-)
:)
participants (2)
-
Esteban A. Maringolo -
Sven Van Caekenberghe