I lie it => I like it (and not a lie at all)
On Wed, Aug 21, 2013 at 10:55 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:
> to be honest I thought those were Symbols rather than some type/brand
> representation and as "symbols" I've shimmed them too.
>
> Float32Array is a thing already, I honestly wouldn't mind Int32, Uint32,
> Uint64, Float32, Float64 and other constructors too in the global scope
> since I don't see any other possible usage for those constructors if not
> this ... we shouldn't really fear to make sense with extra global stuff, it
> avoids a lot of repeated shortcuts, IMO
>
> In SpiderMonkey there is already the ctypes namespace and I agree, as long
> as it's meaningful (and hopefully not so boring to write every time), a
> namespace would work and look way better.
>
> B as Binary Object or b, as binary namespace or even binary would be OK
> **but** this stuff has been renamed already into Typed Object so binary
> should be left aside ..
>
> T as entry point for Types ... I lie it but I am sure somebody will laugh
> about a single char namespace, even if T is used everywhere to describe
> Types indeed in all other programming languages ...
>
> typed would be meaningful too, together with types ... and probably
> TypedObject too but latter one is very "boring" to write each time so it
> will be a mandatory shortcut for every single closure that would like to
> use it (at least that's what my crystal ball says ^_^)
>
> My 2 cents
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Wed, 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:
>>>>>>>
>>>>>>> 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
>>
>>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
