Claus Reinke wrote:
When you write about "could be" or "ought", I suggest grounding what
you write in what "is". There is zero chance of an FFI standard
emerging in the foreseeable future in Ecma TC39.
The current ES FFI is the host object specification.
Oh please. "FFI" means more than any old API or interface between
foreign or "host" code and native (in the ECMA-262 sense) code. An FFI
means low-level access, the ability to call C or C++ code -- for
instance an FFT implementation, the topic that spawned this thread.
In a vacuous sense, yes: the DOMs are generally implemented via C++, and
the ECMA-262 spec imagines their objects as "host objects". But there
are tons of loopholes and massive underspecification!
Indeed you cannot build a browser in pure JS right now, since JS cannot
express all the magic that real-world DOMs require. You cannot talk
about all the native data types (int64 and uint64 are particularly
painful gaps).
Saying the "host object specification" (more ilke "lack of
specification") is an "FFI" is almost a fraud. It debases what is
usually meant by "FFI" to a much less meaningful and useful notion. In
practice it does not help in your quixotic hope to standardize a real
FFI among all browser vendors -- which is not gonna happen any time
soon, and not via Ecma or the W3C.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
