is T as single top level object an option?
is any of these an option: typed, types, type, or TypedObject ?
if not, which one would be ?
On Wed, Aug 21, 2013 at 12:09 PM, David Herman <dher...@mozilla.com> wrote:
> 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
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
