> This reminds me of a different topic: foreign function interface. > [...] > Thoughts?
1. I'm not sure this belongs in ES 2. If TC-39 starts looking at this, I would like to contribute somehow. I have significant experience in this area, and can share knowledge gleaned from an ES-centric implementation which is not related to Python's c-types. Wes On 21 May 2012 12:20, Claus Reinke <[email protected]> wrote: > Once we have modules, should we have a place other than ECMA-262 >>> to define standard host-environment libraries that ship with browsers? >>> >> >> Like the DOM?? ;-) >> >> ..criteria for which libraries might be within the prevue of TC39: >> >> >> * it requires extensions to the base language syntax or semantics or core >> libraries >> * it is of general utility in a variety of hosting environment, not just >> the browser >> * it must be "baked in" to an implementation >> * it raises significant interoperability issues that are solvable at the >> specification level >> * TC39 has the appropriate domain expertise or experts are willing to >> join and participate in TC39 >> > > This reminds me of a different topic: foreign function interface. > > Your first reaction might be: ES can't/shouldn't have any FFI! > > In practice, FFI's exist in various forms already. Chapter 15 > and DOM functions spring into existence seemingly out of > nowhere (there is no ES code that says "there should be a > 'createElement'", no standard prelude that says "'slice' exists > and works on Array-like things"). Much of feature-testing > tries to secure the gaps created by implicit FFI. > > Projects needing device access from ES found work-arounds > that support general, though not necessarily efficient, foreign > function access. Things like Phonegap are entirely based on > such work-arounds. > > JS implementers experimenting with device access just > provide foreign functions implicitly, implementation-specific. > > If ES had a foreign function interface (FFI) to specify how foreign > functionality could be imported into ES code, that might: > > 1 help to document current base functionality in code > (there could be standard libraries listing "pre-defined" > functions imported from the host environment) > > 2 provide a window for optimized, cross-browser > implementation of device access, without the work-arounds > currently employed in Phonegap/Cordova and related projects > > Roughly, there would be ES source syntax for linking an ES > identifier to foreign code, and ES engine support for calling > that foreign code whenever the ES identifier is called in ES code. > > Thoughts? > Claus > > > -- Wesley W. Garland Director, Product Development PageMail, Inc. +1 613 542 2787 x 102
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
