Yeah, I regretted posting that 2nd half. I don't use any native modules
myself except the one to return decoders out of ports. And I was getting by
without it via ports, although somewhat less optimally. Maybe some people
really need native stuff, though. I haven't. (And I'm willing to monkey
patch what I use native for now if need be.)
On Friday, March 24, 2017 at 1:48:01 PM UTC-5, Kasey Speakman wrote:
>
> Indeed, the post mentions renaming Native to Elm.Kernel and ending the
> native module whitelist (sortof). Expectation management.
>
> User native module blocking was not mentioned. In our current Javascript
> ecosystem such a thing would make Elm non-viable.
>
> Well, except that repo-forking and monkey-patching exist.
>
> On Friday, March 24, 2017 at 6:42:34 AM UTC-5, Rupert Smith wrote:
>>
>> On Thursday, March 23, 2017 at 8:15:51 PM UTC, Simon wrote:
>>>
>>> It's pretty clear that these practices are frowned upon, but the shift
>>> to 'kernel' sounds like a plan to squeeze the pragmatic programmer's
>>> options further. I hope that's not the case.
>>>
>>
>> I think all that is happening is that Native is being renamed to Kernel
>> to reduce confusion. At the moment when we say 'Elm' and 'native' in the
>> same sentence we could mean an Elm Native module used to implement its
>> kernel, or native javascript code through ports.
>>
>> I can't be certain of the details but I think your function would just be
>> re-written as:
>>
>> var _user$project$Kernel_Msgpack = function() { ... }
>>
>> But you won't be able to publish it officially and will have to use
>> elm-github-install.
>>
>> It makes sense to me anyway, the 'kernel' needs to be carefully managed
>> as the language takes shape.
>>
>>
--
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.
