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 <[email protected]> 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 <[email protected]> wrote: > On Wed, Aug 21, 2013 at 6:50 PM, K. Gadd <[email protected]> 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 <[email protected]> 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 > <[email protected]> wrote: > sorry, point 3 was actually the question about point 2 > > > On Tue, Aug 20, 2013 at 6:20 PM, Andrea Giammarchi > <[email protected]> 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 > <[email protected]> wrote: > Awesome, thanks! > > > On Tue, Aug 20, 2013 at 4:12 PM, David Herman <[email protected]> wrote: > On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi <[email protected]> > 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
