On Wed, Aug 21, 2013 at 7:42 PM, 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?
>
I really hope that uint64 from value type spec and uint64 from typed object
spec are one and same thing (we now in typed objects spec allow using
uint8/uint16/.. &co to be used as conversion functions).
> 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:
>>>>>>
>>>>>> 1. string and boolean are mentioned, but nowhere in your
>>>>>> `struct.js` prolyfill code. Will string and boolean be accepted?
>>>>>> 2. `Object` and `Any` are mentioned, but exported as object and
>>>>>> any in your `struct.js` prolyfill example. W
>>>>>> 3. 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
