Third day rough meeting notes. Waldemar
instanceof trap for proxies: Withdrawn. Agreed to drop it for now. Proxy default forwarding handler. Agreed that there should be an easy way to delegate to a default forwarding handler. Waldemar: Why not use prototypes to do this? MarkM, others: Would work, but need to write a proposal for it. MarkM: Arguing for simplicity (understandability) of the modules proposal Discussed the merits of modules, asynchrony, scoping, and evaluation phasing. Agreed that static resolution of bindings should produce results indistinguishable from later dynamic resolution of those bindings. Thus, for example it's not ok to asynchronously import * into an outer lexical scope. Also need to ensure that asynchronously loading multiple scripts on a page doesn't violate this rule for the outer lexical scopes, perhaps by making the "global" scope no longer be reflected as an object. DaveH: Would like to see Harmony lexically scoped all the way up. Discussion of IEEE 754r decimal cohorts. Debate over whether for-in should be conceptually restricted to iterating only keys or whether users should be able to do things like: for (var val = values(x) Other points of contention: Iterating keys of an array should return numbers or strings? What should be the syntax for general iteration? Provide a different syntax for user-defined iteration? for (var key : iterator)? Provide a way to iterate only the shallow enumerable properties of an object? Consensus that we should have iterators. Generators: Need to have a distinctive syntax in the preamble to distinguish them from functions. Finally inside generators is also an issue because it might not run. Waldemar: don't allow yield inside a try. Binary data: We have array buffers (not on wiki) and the binary data spec on wiki. Array buffers allow accidental aliasing and endian dependence, and we'd like to not have them. Two very distinct use cases: WebGL arrays: endian-ignorant, fixed size, preallocated File parsing and other such I/O: need to explicitly specify endianness, dynamically construct representation, deal with variable-sized items such as strings. Endianness is a property of the i/o routines, not of the underlying data buffer. An arraybuffer is like a void* -- it's a container for view data structures to index into, where those other data structures impose a structure on a slice of the arraybuffer. DaveH: Would be good to enforce no aliasing of views into arraybuffers. Debate over what primitives should be supported: Waldemar: In-memory contiguous buffers that allow pointers to simple things such as strings. Example with three congiguous records: int int char* -> "Hello" int int char* -> "World" int int char* -> "\n" Each record is fixed-size and has a fixed contiguous structure but whose layout and exact byte size is otherwise invisible to the ECMAScript programmer. The records contain pointers to the strings, but the strings themselves are stored somewhere else on the heap. There should be no way to read/write these into a file except by explicitly describing how it's serialized or deserialized. Of course, all this could also be done using traditional ECMAScript arrays and objects but at a much higher cost when the data is things like graphics data. DaveH: An in-memory array of bytes (like an arraybuffer) together with ways to map views onto it to interpret things like ints, strings, or offset-pointers in some external data format (such as a JPEG). Waldemar's objections to providing views into an in-memory array of bytes: - There is a huge menagerie of basic data types used in files: Many different kinds of string termination, many different kinds of offsets and record counts, computed lengths, etc. - This structure is not appropriate for general modifications. An ECMAScript program cannot practically insert something into the middle without adjusting offsets, lengths, etc. in the block records around the inserted data. Instead, the offsets, lengths, etc. should be consumed by deserialization and generated by serialization. Turns out that the GL interface doesn't let ECMAScript write directly into GPU memory. The methods make copies as needed. More discussion of data buffers. _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss