Re: Binary Data types in window context (was Some Typed Objects Confusion)
Agreed, I'll remove them from the polyfill. On Wed, Aug 21, 2013 at 10:34 PM, David Herman dher...@mozilla.com wrote: On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote: 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). Agreed, and my feeling is that for now we should leave them out. They can be added to the API once the value type exists. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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.orgwrote:
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.orgwrote:
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.comwrote:
On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
[In this page](
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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.orgwrote:
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.orgwrote:
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
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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:
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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
Re: Binary Data types in window context (was Some Typed Objects Confusion)
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.orgwrote:
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.orgwrote:
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.comwrote:
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
Re: Binary Data types in window context (was Some Typed Objects Confusion)
On Aug 21, 2013, at 12:49 PM, Dmitry Lomov dslo...@chromium.org wrote: 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). Agreed, and my feeling is that for now we should leave them out. They can be added to the API once the value type exists. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
