Maybe the word "update" would have been more appropriate? As far as I can
tell the only Date constructors are fromString, fromTime, and now. For
Records you can write { model | x = 5 }, but to get a Date with a different
month you need to convert it to a Time or worse a String before you get a
new Date. This isn't so much about my particular problem (which is to get
the Date of the soonest Monday from now; something I can definitely do
using elm-date-extra) as it is about the core library missing what seems to
me to be fundamental functionality.
On Sunday, June 19, 2016 at 7:02:47 PM UTC-4, John Mayer wrote:
>
> Why would you still call it a setter if it's going to create a new object?
> Just create a new object, and use that.
>
> This sounds like an XY problem. Why do you think you need this?
> On Jun 19, 2016 6:00 PM, "Dan P" <[email protected] <javascript:>> wrote:
>
>> I appreciate the immutability part, but we can make these setters into
>> pure functions by creating new Date objects with each call.
>>
>> Secondly, when you're rewriting pure functions provided by the JS API
>> itself, the only thing you do is increase the chance of an implementation
>> mistake. The only thing that isn't totally uniform across browsers is
>> Date.parseString(). There are things that can be improved, like how Haskell
>> uses types to distinguish UTCTime and LocalTime, but don't fix what ain't
>> broke.
>>
>>
>> On Sunday, June 19, 2016 at 5:37:15 PM UTC-4, Joey Eremondi wrote:
>>>
>>> reproduces working JS APIs
>>>
>>>
>>> This is the goal! Reproducing libraries in pure Elm is much safer and
>>> more desirable than writing wrappers around JS.
>>>
>>> Make sure that whatever you do, you respect Elm's philosophy: all data
>>> is immutable, and side-effects are always wrapped in a Task or a Cmd.
>>>
>>> On Sun, Jun 19, 2016 at 1:31 PM, Dan P <[email protected]> wrote:
>>>
>>>> I realize elm-date-extra <https://github.com/rluiten/elm-date-extra>
>>>> exists,
>>>> but it's bloated, (apparently) unstable, reproduces working JS APIs, and
>>>> is
>>>> not likely to be merged to core any time soon[1]. I'm considering making a
>>>> simplified fork of the former, but this rejected pull request
>>>> <https://github.com/elm-lang/core/pull/214> gives me pause. Can anyone
>>>> more familiar with the Elm ecosystem please advise?
>>>>
>>>> [1]: Not to say that it doesn't also provide useful functionality! But
>>>> core.Date is a little spartan, don't you think?
>>>>
>>>>
>>>>
>>>> On Sunday, June 19, 2016 at 3:03:51 PM UTC-4, Dan P wrote:
>>>>>
>>>>> (e.g. Date.setDate() in JS)
>>>>>
>>>>> Or would a pull request not be in vain?
>>>>>
>>>>> Compare:
>>>>> http://package.elm-lang.org/packages/elm-lang/core/4.0.1/Date
>>>>>
>>>>>
>>>>> https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Date
>>>>>
>>>>> --
>>>> You received this message because you are subscribed to the Google
>>>> Groups "Elm Discuss" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to [email protected].
>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>
>>> --
>> You received this message because you are subscribed to the Google Groups
>> "Elm Discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected] <javascript:>.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
--
You received this message because you are subscribed to the Google Groups "Elm
Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
