[squeak-dev] Status of date problem

Chris Muller asqueaker at gmail.com
Sat Mar 19 15:38:31 UTC 2016


Woops, I see I made a typo, I said I wish to keep #nowWithOffset:, but
in fact, that's the one you (rightfully) deprecated.  #nowAtOffset: is
the new one which I wish to keep.

Your concern seems to be either about the size of the API, or the
rightness of having #nowAtOffset: as a constructor.

My interest is for the API to be conventional and consistent, and by
that, I mean, the user should expect to be able to interact strictly
with the constructor methods to obtain the instance they want, as is
the case with all value objects, and not have to create an interim
instance first.

Clearly, the attributes of a DateAndTime are the ones settable by this
constructor, #year:month:day:hour:minute:second:nanoSecond:offset:.

offset: is the last argument.  Its already established as a part of
constructor API.  #nowAtOffset: simply mirrors that, except supplies
the "nowness" from the prim and lets the user vary the location.  I
really feel this is a good API design to keep nowAtOffset:.

I actually think we should get rid of DateAndTime>>#offset:, or at
least make it a private (or initializing) method.

Finally, DateAndTime class>>#now:offset: should be made private.  Its
private, right?


>>> Since “utcOffset:" appears to do the right thing I’d actually prefer it to the “nowAtOffset:” you just introduced. E.g. to get the current time in LA you could simply use
>>>
>>> DateAndTime now utcOffset: -7 hours
>>>
>>> No need for a new message. Arguably this is what “offset:” should do, and it would if the implementation was utc-based (as is David’s) rather than local-time based.
>>
>> I wish to keep #nowWithOffset:.  DateAndTime's are "value" objects --
>> like Points and Fractions.  I never want to write code that sets any
>> state on existing DateAndTime objects, not even their #offset.
>
> #offset: does return a new instance.
>
>> Value objects are only ever created, and then their state never change
>> in 99% of cases.  Magma treats DateAndTimes as immutable in the
>> database for performance -- it doesn't bother to check if they
>> changed.
>
> Yep. Same in general.
>
>> Semantically, #utcOffset: doesn't mean anything to me.  What is a "UTC
>> offset?"
>
> Agreed.
>
>> #nowWithOffset: sorts in the list next to #now, and makes
>> it abundantly clear to users what use-case it handles.  I wish to keep
>> it.
>
> How about one character more? A space?
>
> ... now withOffset: ...
>
> I think composability is preferable to an explosion of one-off specialized methods. I'd rather deprecate both #offset: and #utcOffset: and start doing the Right Thing.
>
> - Bert -
>
>


More information about the Squeak-dev mailing list