<div dir="ltr"><span style="font-family:arial,sans-serif;font-size:13px">I lie it => I like it (and not a lie at all)</span><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 10:55 AM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">to be honest I thought those were Symbols rather than some type/brand representation and as "symbols" I've shimmed them too.<div>
<br></div><div>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</div>

<div><br></div><div>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.</div><div>

<br></div><div>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 ..</div><div><br></div><div>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 ...</div>

<div><br></div><div>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 ^_^)</div>

<div><br></div><div>My 2 cents</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div>

<br></div><div><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 10:42 AM, K. Gadd <span dir="ltr"><<a href="mailto:kg@luminance.org" target="_blank">kg@luminance.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><moving back onto list><br><div><br>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.<br>



<br></div><div>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?<br>



<br></div><div>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.<br>



<br></div><div>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)<br>



</div><div><div class="gmail_extra"><br></div><div class="gmail_extra">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).<br>



<br></div><div class="gmail_extra">-kg<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 10:36 AM, Dmitry Lomov <span dir="ltr"><<a href="mailto:dslomov@chromium.org" target="_blank">dslomov@chromium.org</a>></span> wrote:<br>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>On Wed, Aug 21, 2013 at 6:50 PM, K. Gadd <span dir="ltr"><<a href="mailto:kg@luminance.org" target="_blank">kg@luminance.org</a>></span> wrote:<br>



</div><div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">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)<br>




</div></blockquote><div><br></div></div><div>Yes, this is where we are at now.</div><div>Maybe we should pack the whole thing into a module.</div><div><div><div><br></div><div>Dmitry</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr">

</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div>On Wed, Aug 21, 2013 at 4:21 AM, Dmitry Lomov <span dir="ltr"><<a href="mailto:dslomov@chromium.org" target="_blank">dslomov@chromium.org</a>></span> wrote:<br>






</div><div><div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>string, boolean, object and any are all lowercase (we should fix the wiki)</div>
<div><br></div>FWIW, I am already working on a new version of polyfill. It is fully ES5.<div>

Here is a pull request: <a href="https://github.com/dherman/structs.js/pull/12" target="_blank">https://github.com/dherman/structs.js/pull/12</a> - I'll merge it soon, and work more to cover everything in the proposal.</div>







<div><br></div><div>Thanks,</div><div>Dmitry<br><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div>On Wed, Aug 21, 2013 at 3:21 AM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>







</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr">sorry, point 3 was actually the question about point 2</div><div><div>

<div class="gmail_extra">
<br><br><div class="gmail_quote">On Tue, Aug 20, 2013 at 6:20 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Uhm, just a couple of extra question about that page if/when you have time:<div><div><ol><li>string and boolean are mentioned, but nowhere in your `struct.js` prolyfill code. Will string and boolean be accepted?</li>









<li>`Object` and `Any` are mentioned, but exported as object and any in your `struct.js` prolyfill example. W</li><li>Which is the right way?</li></ol></div><div>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)</div>









<div><br></div>Thanks.</div></div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Aug 20, 2013 at 4:55 PM, Andrea Giammarchi <span dir="ltr"><<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>></span> wrote:<br>









<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Awesome, thanks!</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Tue, Aug 20, 2013 at 4:12 PM, David Herman <span dir="ltr"><<a href="mailto:dherman@mozilla.com" target="_blank">dherman@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi <<a href="mailto:andrea.giammarchi@gmail.com" target="_blank">andrea.giammarchi@gmail.com</a>> wrote:<br>











<br>
> [In this page](<a href="http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects" target="_blank">http://wiki.ecmascript.org/doku.php?id=harmony:typed_objects</a>), and in the latest meeting note too, I can read both uint8 and Uint8, as example.<br>











<br>
</div>Bug. Fixed, thanks.<br>
<div><br>
> **The Question**<br>
> 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` ?<br>
<br>
</div>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).<br>
<div><br>
> 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.<br>
<br>
</div>Nikhil Marathe and Niko Matsakis are actively working on the implementation for SpiderMonkey:<br>
<br>
    <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=578700" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=578700</a><br>
<br>
Dmitriy Lomov is actively working on updating the prollyfill to match the current API:<br>
<br>
    <a href="https://github.com/dherman/structs.js" target="_blank">https://github.com/dherman/structs.js</a><br>
    <a href="https://github.com/dherman/structs.js/pull/12" target="_blank">https://github.com/dherman/structs.js/pull/12</a><br>
<br>
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.<br>
<br>
Dave<br>
<br>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><div>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div></div></div><br></div>
</blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div>