Ah entirely replace them Yes, that’s what I proposed in an earlier message in this thread.
An action manager like mentioned above could make it very easy then, especially if it was a state-based action mapper as is common in many windowing systems. An action manager would be something else, and not needed for the cases I showed. Concerning extending the Keyboard API in a different direction (stateful), see the “conditions” set out by Evan in the README: https://github.com/elm-lang/keyboard/blob/master/README.md. Just many experiences over many decades of seeing once good API’s explode and become a mess,… You may find that what you experienced in other languages and frameworks about how APIs develop over time does not translate to how things happen in the Elm sphere, due to the way Evan manages things. In particular for something like the Keyboard API, which depends on native code and thus will continue to stay under his control. Only one? Yes, indeed. Note what I wrote there. It talks about filtering subscriptions. All the examples you mention do not seem to be about subscriptions, but instead about updates that come from other sources, probably from HTML events. Where (except keyboard handling) have you wanted to apply a filter function to a Sub-typed thing? (Leading us away from keyboard, so maybe this is more suitable to continue in the other thread about generic subscription filtering.) 2016-08-10 20:46 GMT+02:00 OvermindDL1 <overmind...@gmail.com>: > On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote: >> >> I like your general solution, OvermindDL1, but I don't think it is >> mutually exclusive with improving the keyboard api as Janis suggested. For >> general cases, your solution is great. But as several people already said, >> with Keyboard it is practically always the case that you want to filter, >> ergo it makes sense to "bake it into the api" of keyboard. >> > > True yeah. Actually for a keyboard a state-mapper would probably be > best. Being able to register keys to an action and being able to re-map > them with ease. Could make an easy set of functions for that. > > > On Wednesday, August 10, 2016 at 12:20:46 PM UTC-6, Daniel Bachler wrote: > >> So from me +1 for Janis revised proposal for this specific case, but also >> a thumbs up to the general approach to filtering. OvermindDL1, do you want >> to write a post about this showing it to newcomers in more detail? >> > > Already did: https://groups.google.com/forum/#!topic/elm-discuss/u_ > 30Y4iueRY > > > > On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer > wrote: >> >> I don’t understand your concern. The Keyboard API would not get larger, >> because I have proposed to replace three old functions by three new >> functions. >> > Ah entirely replace them. An action manager like mentioned above could > make it very easy then, especially if it was a state-based action mapper as > is common in many windowing systems. > > > On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer > wrote: > >> The rest of your concerns build on that concern (ballooning), so seem >> immaterial to me at the moment. >> > Just many experiences over many decades of seeing once good API's explode > and become a mess, bit paranoid about it... >.> > > > On Wednesday, August 10, 2016 at 12:21:45 PM UTC-6, Janis Voigtländer > wrote: > >> Generally, if you haven’t yet, you might want to go back and read the >> original “generic subscription filtering” thread I pointed to in the first >> post, in full. And I may add that since then I have been on the lookout for >> specific cases where subscription filtering is desired. I haven’t found >> enough cases to convince myself that a generic mechanism is called for. In >> fact, I found *exactly* the one, keyboard handling, that I am addressing >> here. I naturally have looked in only specific places, but let me say that >> I have had more than those five students coding Elm projects. >> > Only one? I've cleaned out a half-dozen messages from my big app and > still have plenty more to work through as I notice them. It has changed > the code count by (checking git) total of -77 lines (everything is > `elm-format`'d as well), which is fairly significant for only handling 6 > message types so far. > > But of the filtering I do so far, I have two TEA-modules hooked in (my own > Helpers and elm-mdl), handle the Scroll event (I only load older messages > if the scroll hits within 16 pixels of the top of the div), as well as 3 > notification ones that I ignore if the relevant room is not visible at the > moment (the primary path already registers others to the top notification > listing). I am really liking how it looks though, flattened 'update' > significantly in some hairy sections. :-) > > >> -- > 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.
