A DateAndTime that does not understand #date or #time?
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight) Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D How come that the most basic ones are being omitted? Am I missing something? sebastian o/
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy returning to the question.. is that omission intentional then? I mean.. There are counter intuitive things that are cool. This isn't one of those. This one sounds a lot against intuition for no good reason sebastian o/ On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
I canât defend the API choice. But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work. On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy
returning to the question.. is that omission intentional then?
I mean..
There are counter intuitive things that are cool.
This isn't one of those.
This one sounds a lot against intuition for no good reason
sebastian
o/
On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
Yeah Sven, I know timezones can be hell. Actually for me this isn't an issue as already ported my code with asDate and asTime. What worries me is the thinking behind that omission Why? Because you don't know where it will bite you next. But it will And it wont be intuitive On Jan 3, 2014, at 4:20 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I canât defend the API choice.
But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work.
On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy
returning to the question.. is that omission intentional then?
I mean..
There are counter intuitive things that are cool.
This isn't one of those.
This one sounds a lot against intuition for no good reason
sebastian
o/
On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
Sebastian You should consider that often there were no decision: just old code designed sometimes even before Design Patterns and any of the book on oo design we know today. No more. Then the system grew organically, then we arrived and started to revisit but sometimes we did not see the original intention because they were many layers/authors/stylesâ¦. Now if you want to see the situation improving: build a serious case, spend some time analysing it (I mean more than writing a mail) and make a proposal. We will discuss and probably converge and improve the system. Stef On 03 Jan 2014, at 19:41, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Yeah Sven, I know timezones can be hell.
Actually for me this isn't an issue as already ported my code with asDate and asTime.
What worries me is the thinking behind that omission
Why?
Because you don't know where it will bite you next.
But it will
And it wont be intuitive
On Jan 3, 2014, at 4:20 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I canât defend the API choice.
But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work.
On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy
returning to the question.. is that omission intentional then?
I mean..
There are counter intuitive things that are cool.
This isn't one of those.
This one sounds a lot against intuition for no good reason
sebastian
o/
On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
Makes sense. Thanks Stef I will On Jan 3, 2014, at 7:41 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
Sebastian
You should consider that often there were no decision: just old code designed sometimes even before Design Patterns and any of the book on oo design we know today. No more. Then the system grew organically, then we arrived and started to revisit but sometimes we did not see the original intention because they were many layers/authors/stylesâ¦.
Now if you want to see the situation improving: build a serious case, spend some time analysing it (I mean more than writing a mail) and make a proposal. We will discuss and probably converge and improve the system.
Stef
On 03 Jan 2014, at 19:41, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
Yeah Sven, I know timezones can be hell.
Actually for me this isn't an issue as already ported my code with asDate and asTime.
What worries me is the thinking behind that omission
Why?
Because you don't know where it will bite you next.
But it will
And it wont be intuitive
On Jan 3, 2014, at 4:20 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
I canât defend the API choice.
But consider this: contrary to the name, a DateAndTime is much more that just a Date + a Time, it has a timezone offset and fractional seconds. That could be reason why there are #asDate and #asTime as conversion methods instead of #date and #time as accessors. On the other hand, there are lots of other accessors for all components. Maybe that is why #date and #time were not implemented: you would expect taking the date and time from a dateAndTime and composing them again would yield the original object, but that would not work.
On 03 Jan 2014, at 19:03, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
yeah is what I'm using now but the 'as' means conversion while the #date and #time suggest delegating access to the other guy
returning to the question.. is that omission intentional then?
I mean..
There are counter intuitive things that are cool.
This isn't one of those.
This one sounds a lot against intuition for no good reason
sebastian
o/
On Jan 3, 2014, at 3:55 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 03 Jan 2014, at 18:50, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
#asDate and #asTime ?
sebastian
o/
BTW DateAndTime today class = DateAndTime. true DateAndTime today asTimeStamp class = TimeStamp. true DateAndTime today asTimeStamp asDateAndTime = DateAndTime. false (stays as TimeStamp) o.O On Jan 3, 2014, at 3:50 PM, Sebastian Sastre <SEBASTIAN@FLOWINGCONCEPT.COM> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
sebastian
o/
On 03 Jan 2014, at 18:57, Sebastian Sastre <sebastian@flowingconcept.com> wrote:
BTW
DateAndTime today class = DateAndTime. true DateAndTime today asTimeStamp class = TimeStamp. true DateAndTime today asTimeStamp asDateAndTime = DateAndTime. false (stays as TimeStamp)
o.O
And TimeStamp is on the way out since it hardly differs from DateAndTime and confuses the hell out of everyone. This discussion is independent of which name is best.
On Jan 3, 2014, at 3:50 PM, Sebastian Sastre <SEBASTIAN@FLOWINGCONCEPT.COM> wrote:
How are we going to tell that our DateAndTime does not understand #date nor #time? (and keep our face straight)
Sorry for the drama but hey... the raison d'être, its meaning, the purpose in the life of a DateAndTime is to make you able to send messages about date and time :D
How come that the most basic ones are being omitted?
Am I missing something?
sebastian
o/
On Jan 3, 2014, at 4:01 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
TimeStamp is on the way out since it hardly differs from DateAndTime and confuses the hell out of everyone. This discussion is independent of which name is best.
I'm cool about keeping only one. Omitting the basics, breaking the most elemental intuitive expectations? not cool
participants (3)
-
Sebastian Sastre -
Stéphane Ducasse -
Sven Van Caekenberghe