Hi Mike (mckoss), Yes, when compared with the specification, I am using a risky parameter format. For perspective, parameter formats evolve, and do so with less pain than from changes to API methods and objects. Just look at YUI's mixed use of configuration objects in place of individual arguments.
Given this, I hope you'll merit Flow for it's approach to coding contractual, policy-based functions: defining explicit relationships between functions. There are several approaches which can achieve this same goal (from currying and AOP, to custom-events and simple callbacks), and numerous libraries that implement them (like, Dojo). Whether or not Flow changes how you define these relationships (i.e., the parameter format in question), whether due to peer or browser pressures, the approach is sound and favors agile-development. A future version of Flow will likely support an alternate format, for describing these relationships. That said, the current format is not a "defect", since it works on every major web browser. (Discovering a JavaScript engine which fails the test suite, would have me say otherwise.) Regarding your thoughts as to whether anyone would use Flow: they already are, at my workplace. Another company is considering the risks, and I'll be presenting Flow to them next month. On Apr 27, 12:25 am, mckoss <[email protected]> wrote: > I don't think you will get anyone to use your library with this defect > (conscious or not). > > On Apr 26, 8:27 am, bemson <[email protected]> wrote: > > > > > > > > > Hey Stefan, > > > Yes, though it works in every browser today, depending on the order of > > object-properties was a conscious risk. Naturally, a future version > > could use a dual implementation that considered arrays of object- > > collections - the same way DOM nodes are structured (i.e., the > > childNodes array). > > > On Apr 26, 5:33 am, Stefan Weiss <[email protected]> wrote: > > > > On 26/04/11 05:08, bemson wrote: > > > > > My name is Bemi Faison. I'm the author of Flow, a framework for > > > > defining and executing related functions. > > > > (https://github.com/bemson/Flow/ > > > > ) > > > > > I'm of the notion that the concept is more valuable than my > > > > implementation. To that end, I have completed the API documentation, > > > > and recently updated use-cases. However, I don't have an academic > > > > background, and have struggled with how to present and position Flow, > > > > in the context of existing programming paradigms. > > > > > I seek assistance with explaining my approach, writing use-cases, and > > > > sharing my vision with the JavaScript community. I welcome all > > > > comments, critiques, concerns and inquiries. > > > > Looking at this page of code examples - > > > > https://github.com/bemson/Flow/wiki/Flow-Use-Cases > > > > - it appears that Flow relies on the order in which object properties > > > are returned when you iterate over them ("Flow traverses a program > > > sequentially (e.g., from first to last)"). If that's correct, you may > > > want to rethink your approach. > > > > The language makes no guarantees that the iteration order for properties > > > will remain constant, or even predictable. Recent developments in script > > > engines (eg, Chrome, Opera and IE) show that engine developers are > > > willing to using optimizations which will cause older scripts to break, > > > if they mistakenly relied on a certain iteration order. > > > > It may appear to work the way you expect in current browsers, but that's > > > just a coincidence, and not something I would use as the basis for a JS > > > framework. If you need functions to be executed in a certain order, > > > you'd be safer if you used an array. > > > > -- > > > stefan -- 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]
