Scott Sauyet wrote:
>
> Perhaps in a more complex scenario? I'm trying to see how your
> example is more readable than a naive variation. [...]
> [...]
> So I'm simply not seeing the simplicity.
>
Flow breaks down complexity into granular structures called "states".
Simple projects would only have few states, which would make such
structure seem like overkill. Complex projects benefit from this
structure, because encapsulation helps compartmentalize code. Flow is
useful since this structure scales (is repeatable), but does decrease
readability in smaller projects.
Readability is also subjected to what you want to comprehend. Are you
reading code to understand _how_ something happens, or _what_ *is*
happening? Clearly both are parts of comprehension, but I'd argue that
the latter is more important. In order to write JavaScript,
programmers must deconstruct context (e.g., goals and purpose) into
actionable statements. Thus, "readable JavaScript" really means, the
ease with which we can reconstruct the context. If you've found
yourself studying code while mumbling, "What were they doing here?" or
"Where does this function go?", that's our minds trying to reconstruct
context.
I feel Flow is more readable when you're looking for context, as
opposed to actions. Action-based code (like your example) can be very
elegant and readable, but requires this extra effort of comprehension.
This is very much the difference between imperative and declarative
languages, and I've found value when mixing the two. Flow does this by
making context first-class members of your code.
>
> What is the advantage of `targeting` versus `calling` beyond the
> tedium of coding wrappers where needed? Is it the more declarative
> definition? It's nice to have functions guard their own pre- and post-
> conditions rather than have the calling code have to check them, but
> does that make enough difference to call for a fairly intrusive
> framework to manage it?
>
Closed systems make for confident systems. Related functions often
work with and rely on each other. In such cases it's important to
manage the state of their execution environment. If we only call
functions directly, we risk not managing that state, or requiring that
each function performs more concurrency logic. It is declarative, the
way a SQL statements tells the database (a closed system) to do
something, without worrying how the pre/post actions. With Flow, you
are "querying" states of your program, letting Flow handle what's
needed before reaching that state.
> > Plus, the _map_ construct masks the
> > underlying framework, letting external/existing routines remain
> > ignorant of the logic behind each "call".
>
> Are all functions encapsulated this way public? Or is there a way to
> hide implementation details?
I don't quite follow what you're asking. Flow does not provide direct
access to any functions. The "map" is a linked-list of closured calls,
which direct Flow to their corresponding. It's also a convenience you
don't have to use.
var aProgram = {...};
var myMap = new Flow(aProgram);
var myFlow = new Flow(aProgram, true);
myMap.some.state.I.want.to.target(5);
myFlow.target('/some/state/I/want/to/target', 5);
The last two lines are the same. Using API methods with myFlow, you
can direct your Flow programmatically.
> Yes, that's cleaner, IMHO. I would prefer `flow` or something more
> descriptive than `that`, but it's a minor concern.
I didn't want to confuse folks with a variable name that was similar
to the constructor. Maybe in the next revision...
>
> It's great to hear that you're open to change.
>
No point in resisting it! Many many thanks for the questions!
- bemson
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
