Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sven Van Caekenberghe

On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/
 
 
 
 
 




Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sebastian Sastre
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 sebast...@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/
 
 
 
 
 



Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sven Van Caekenberghe

On 03 Jan 2014, at 18:57, Sebastian Sastre sebast...@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 sebast...@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/
 
 
 
 
 
 




Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sebastian Sastre
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 s...@stfx.eu wrote:

 
 On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/
 
 
 
 
 
 
 



Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sebastian Sastre
On Jan 3, 2014, at 4:01 PM, Sven Van Caekenberghe s...@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




Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sven Van Caekenberghe
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 sebast...@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 s...@stfx.eu wrote:
 
 
 On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/
 
 
 
 
 
 
 
 




Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sebastian Sastre
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 s...@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 sebast...@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 s...@stfx.eu wrote:
 
 
 On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/
 
 
 
 
 
 
 
 
 
 



Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Stéphane Ducasse
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 sebast...@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 s...@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 sebast...@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 s...@stfx.eu wrote:
 
 
 On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/
 
 
 
 
 
 
 
 
 
 
 



Re: [Pharo-dev] A DateAndTime that does not understand #date or #time?

2014-01-03 Thread Sebastian Sastre
Makes sense.

Thanks Stef I will



On Jan 3, 2014, at 7:41 PM, Stéphane Ducasse stephane.duca...@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 sebast...@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 s...@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 sebast...@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 s...@stfx.eu wrote:
 
 
 On 03 Jan 2014, at 18:50, Sebastian Sastre sebast...@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/