If necessary, i.e. if people want to release it before modules, we can make it available in a single top-level object, but I would not at all favor dumping everything onto the global scope.
Dave On Aug 21, 2013, at 12:07 PM, David Herman <dher...@mozilla.com> wrote: > The intention has always been for them to be in a module. I'll make that > clearer on the wiki. > > Dave > > On Aug 21, 2013, at 10:42 AM, K. Gadd <k...@luminance.org> wrote: > >> <moving back onto list> >> >> It might be worth doing. On the one hand, I don't really feel like these >> names *should* collide with anything, but it seems like the risk is kinda >> high... and it's a little weird seeing them in global scope and having to >> figure out that they're actually types for binary data and not, for example, >> the constructor for boolean or some sort of value type ctor. >> >> Once 64-bit signed/unsigned ints are in will there be two names for those as >> well? I.e. Uint64(...) produces one of the new 64-bit unsigned ints, while >> uint64 is the name you use when creating a StructType to specify the type of >> a field? >> >> If the type names used by binary data actually work as constructors to get >> an instance of that type, that might make it more justified for the names to >> be in global scope, but that seems like probably unmerited scope creep. >> >> Having the types be in a single 'BinaryTypes' namespace or something at >> window-level seems like it would be pretty reasonable; if you're going to be >> referring to types a lot you can pull them into locals, or use 'with' in a >> gross non-strict function (yuck yuck yuck) >> >> I assume specifying type names as strings, i.e. { field: "uint32" } was >> considered and ruled out (it would definitely be strange to mix that with >> passing in actual StructType instances). >> >> -kg >> >> On Wed, Aug 21, 2013 at 10:36 AM, Dmitry Lomov <dslo...@chromium.org> wrote: >> On Wed, Aug 21, 2013 at 6:50 PM, K. Gadd <k...@luminance.org> wrote: >> Does this mean the addition of binary data to a browser defines dozens of >> new names in 'window' scope, like 'string' and 'boolean' and 'uint32' >> alongside existing names? That's kind of surprising to me (though I can >> understand why it might be necessary) >> >> Yes, this is where we are at now. >> Maybe we should pack the whole thing into a module. >> >> Dmitry >> >> >> >> On Wed, Aug 21, 2013 at 4:21 AM, Dmitry Lomov <dslo...@chromium.org> wrote: >> string, boolean, object and any are all lowercase (we should fix the wiki) >> >> FWIW, I am already working on a new version of polyfill. It is fully ES5. >> Here is a pull request: https://github.com/dherman/structs.js/pull/12 - I'll >> merge it soon, and work more to cover everything in the proposal. >> >> Thanks, >> Dmitry >> >> >> >> On Wed, Aug 21, 2013 at 3:21 AM, Andrea Giammarchi >> <andrea.giammar...@gmail.com> wrote: >> sorry, point 3 was actually the question about point 2 >> >> >> On Tue, Aug 20, 2013 at 6:20 PM, Andrea Giammarchi >> <andrea.giammar...@gmail.com> wrote: >> Uhm, just a couple of extra question about that page if/when you have time: >> • string and boolean are mentioned, but nowhere in your `struct.js` >> prolyfill code. Will string and boolean be accepted? >> • `Object` and `Any` are mentioned, but exported as object and any in >> your `struct.js` prolyfill example. W >> • Which is the right way? >> The reason I am asking is to be able to create code that does absolutely >> nothing (for performance reason) but will look like the real thing so I can >> start experimenting with static structures and possibly a develop VS >> production version of an ES3 to ES5 compatible polyfill since I believe your >> code won't run anywhere except in SpiderMonkey (which is OK but it's not >> suitable for a lightweight migration to "structure like" logic) >> >> Thanks. >> >> >> On Tue, Aug 20, 2013 at 4:55 PM, Andrea Giammarchi >> <andrea.giammar...@gmail.com> wrote: >> Awesome, thanks! >> >> >> On Tue, Aug 20, 2013 at 4:12 PM, David Herman <dher...@mozilla.com> wrote: >> On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi <andrea.giammar...@gmail.com> >> wrote: >> >>> [In this >>> page](http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects), and in >>> the latest meeting note too, I can read both uint8 and Uint8, as example. >> >> Bug. Fixed, thanks. >> >>> **The Question** >>> How is `new StructType({x:Uint32, y:Uint32})` supposes to understand the >>> type? `instanceof Uint32` or `typeof v === "uint32"` or ... both in case of >>> `boolean` and `string` ? >> >> Neither. It tells you that the x and y fields have typeof 'number' and that >> their values are constrained to be integers in the range [0, 2^32). >> >>> A bonus question would be: does anybody know when this stuff is planned to >>> go out? Not a single beta/alpha channel is exposing anything at all so far. >> >> Nikhil Marathe and Niko Matsakis are actively working on the implementation >> for SpiderMonkey: >> >> https://bugzilla.mozilla.org/show_bug.cgi?id=578700 >> >> Dmitriy Lomov is actively working on updating the prollyfill to match the >> current API: >> >> https://github.com/dherman/structs.js >> https://github.com/dherman/structs.js/pull/12 >> >> Not sure if anyone on the V8 team (which includes Dmitriy) has started >> implementation but I believe they're interested. Right now Dmitriy is >> focused on the prollyfill and spec. >> >> Dave >> >> >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss