Discuss
  • Some Typed Objects Confusion

Some Typed Objects Confusion

# Andrea Giammarchi (12 years ago)

In this page, and in the latest meeting note too, I can read both uint8 and Uint8, as example.

Same if for all other types included boolean, and string, where these are historically typeof variable without meaning variable is instanceof String or Boolean.

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 ?

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.

# David Herman (12 years ago)

On Aug 20, 2013, at 1:31 PM, Andrea Giammarchi <andrea.giammarchi at gmail.com> wrote:

In this page, 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: bugzilla.mozilla.org/show_bug.cgi?id=578700

Dmitriy Lomov is actively working on updating the prollyfill to match the current API: dherman/structs.js, dherman/structs.js#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.

# Andrea Giammarchi (12 years ago)

Awesome,

# Andrea Giammarchi (12 years ago)

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.

# Andrea Giammarchi (12 years ago)

sorry, point 3 was actually the question about point 2

# Dmitry Lomov (12 years ago)

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: dherman/structs.js#12 - I'll merge it soon, and work more to cover everything in the proposal.

# Andrea Giammarchi (12 years ago)

excellent, I'll keep an eye on that, which is perfect when debug and more checks are needed.

What I meant with previous email is basically summarized in this gist

The fakelyfill ^_^ code is there to offer similar behavior without compromising too much performance.

What I find extremely useful about Typed Objects is not just some WebGL exchange, rather the possibility to finally have proper fixed and fast objects for libraries, database or NoSQL results, and JSON de-serialization.

I really cannot wait to see this happening, places where applications could benefit from Typed Objects, if these will be closely fast as asm.js could be with native, are more than we could think about right now with such JS history/background.

Thanks for working on this and have a nice day.

# David Herman (12 years ago)

Any, String and Object should still be uppercase. The naming convention is: value types lowercase, reference types uppercase.

# Dmitry Lomov (12 years ago)

Hmm really? I am not sure - how this reconciles with existing Object and String? Even if this is imported from a module, the clashing will be unfortunate.

# Andrea Giammarchi (12 years ago)

I guess you would not import/export Object, Boolean and String from a module (while Any will be exported .. uhm, feels weird) ... but for instanceof consistency sake I agree either constructors or lowered_cases pseudo "types"

# David Herman (12 years ago)

Let's take this off-list. Bikeshed territory.

# Andrea Giammarchi (12 years ago)

can you guys please come back with an answer or finalize the decision in the wiki once discussed?

# Brendan Eich (12 years ago)

David Herman wrote:

Any, String and Object should still be uppercase. The naming convention is: value types lowercase, reference types uppercase.

Is String really a reference type? Currently you can't tell, and JS docs and books don't (AFAIK) say "reference type" apart from object (not null; including function). String also happens to spell the constructor/converter function, which sadly both returns a primitive and creates a String object depending on how it is called.

Implementations can support strings using copy and reference types under the hood (short strings get copied). No mutation and no extensibility of the string primitive value type mean no way to tell it's a reference. For these reasons and to avoid the String constructor connotation, I find 'string' winning in this typed objects setting.

# David Herman (12 years ago)

On Aug 21, 2013, at 2:36 PM, Brendan Eich <brendan at mozilla.com> wrote:

David Herman wrote:

Any, String and Object should still be uppercase. The naming convention is: value types lowercase, reference types uppercase.

Is String really a reference type? Currently you can't tell, and JS docs and books don't (AFAIK) say "reference type" apart from object (not null; including function). String also happens to spell the constructor/converter function, which sadly both returns a primitive and creates a String object depending on how it is called.

You can tell, in that a type that includes String must be opaque. The might-be-a-pointer property of a type is observable in the typed objects API in that it cannot expose its backing storage as an ArrayBuffer. Strings necessarily might-be-a-pointer.

I take your point that it's confusing on the primitive/object axis, though.

So... all right, let's break out those paintbrushes. Let's say we use the lowercase naming convention for purely immutable types, independent of whether they might-be-a-pointer. This still leaves Dmitry's question about the unfortunate name collision -- even though modules make this "okay," it's still a PITA in practice not to be able to import Object without shadowing the built-in Object.

Personally I'd be fine with just lowercasing all the things. Brendan, you cared about using capitalization for object types, though. What color is your bikeshed?

# Andrea Giammarchi (12 years ago)

I agree lower ALL the cases is a win ... also because boolean, string, and object, aren't reserved words while function obviously is so with current proposal where object means function too and any includes null there's nothing ambiguous and less to bother about references.