In the lecture Peter links to, the word "closure" is just being used to
mean a function `a -> a`, where the return type matches the argument type.
Like the mathematical sense of "the integers are closed with respect to
addition."

Its a useful property for a function to have, but in the sense used here,
it's not really related to the question of components or private state.

On Mon, Sep 19, 2016 at 10:34 PM, Max Goldstein <maxgoldste...@gmail.com>
wrote:

> Closure sounds like a nice property in theory. In practice, it's built on
> the idea that you have to hide things, because things tend to break and
> encapsulation is the only way to keep that breakage from spiraling out of
> control. But in Elm, things don't break very often, and when they do the
> compiler is there to catch them. So don't worry about components, just use
> functions.
>
> That said, there's a very important point in OP about state for HTML tags.
> For example, the reuse section of the guide  has an example with
> checkboxes. These boxes send messages to toggle their state when they are
> clicked. But, there is no way to pre-populate the state of the checkboxes
> for example with information you get from the server. In another thread, I
> think this is worth discussing. If some HTML components are state full what
> do we do about that, without jumping down the rabbit hole of components?
>
> --
> 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 elm-discuss+unsubscr...@googlegroups.com.
> 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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to