@Scott Scott Sauyet wrote: > This is reasonably well written. It's certainly easy to follow, and > the example is clean. But to me it's missing something basic. Your > guide still really only explains *how* to use Flow. Even after > reading it and reading many of the examples on your site, I'm still > not clear on *why* I'd want to use it.
Firstly, thanks for the compliment! I'll be updating the quality and content of my documentation over time. I haven't nailed down the benefits to using Flow, but here are two: 1) Readability. Like @Dash mentioned, Flow uses a narrative, declarative style, for defining functions and their relationships. Indentation aside, this means code which is easier to follow. I find that readability is critical to productivity, when maintaining code. 2) Control. Flow supports policy-based programming, and introduces the notion of "targeting" instead of "calling" functions. For example, the function "app.data.delete()" should not be immediately accessible, but instead go _through_ some logic that lets you deny the operation. Namespaces provide no control, and wrapping every "important" function in such logic is tedious. Flow supports policy-setting via the order and encapsulation of functions. Plus, the _map_ construct masks the underlying framework, letting external/existing routines remain ignorant of the logic behind each "call". > As to the details, I have two fairly minor quibbles and one more > serious objection. The first is really trivial: what's with the > underscores? Underscores (or something) are used to distinguish components from the names of child states. I could have reserved "main" along with the other component names, but felt a prefix gave me room for future components, and wouldn't hamper authors choices when naming states. It is clunky, but doesn't something have to be? > That internal reference to the external `page` variable is scary. The > object you create here can be aliased and replaced, and such a > reference would then point elsewhere. Can you either use `this` or > pass in a reference to the object? I didn't address this, in order to keep the guide simple. However, I've updated the guide with an alternate component function, which speaks to your concern. Here's a direct link to that section: https://github.com/bemson/Flow/wiki/Using-Flow#s4-1-2 Let me know what you think! > But my largest objection now is the same one that was brought up > earlier in this thread. Using the order of the definitions to > determine the order your functions run is a show-stopper for me. I I feel this discussion has been framed poorly. Browsers have *never* preserved the order of key definitions. (Yes, Chrome's integer-key issue is a duly-noted exception.) I've never inspected the guts of browser code, but will bet that the stacks used to store our key- definitions is the reason their order is "preserved" (i.e., the rule of first-in, first-out). Thus, order is not actively randomized... just ignored. I'm fully aware that some developers prefer ordering with arrays. To that end, I will likely provide a parameter format which will define programs using arrays. I've filed a bug against myself, and you're welcome to contribute your ideas there. https://github.com/bemson/Flow/issues/7 - bemson -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/jsmentors@jsmentors.com/ To search via a non-Google archive, visit here: http://www.mail-archive.com/jsmentors@googlegroups.com/ To unsubscribe from this group, send email to jsmentors+unsubscr...@googlegroups.com
