Having said that, if its an opaque type, you could not supply values yourself, which is where this all started... and I think that is a good idea (for example when importing data). So whilst I think all the points I made in favour of an opaque type are true for this kind of thing in general, for this case I think the need to supply a value is more important. Personally I would like to see support for infinite-precision integers like Python has in JavaScript, but proper integer support would be a start. Cheers, Keean. On 13 November 2010 11:13, Keean Schupke <keean@fry-it.com> wrote: > Hi, > > On 13 November 2010 08:33, Jonas Sicking <jonas@sicking.cc> wrote: > >> On Fri, Nov 12, 2010 at 11:59 PM, Keean Schupke <keean@fry-it.com> wrote: >> > Why not return the full 64bit ID in an opaque object? Maths and >> comparing >> > IDs is meaningless anyway. >> >> Then we'd have to overload both the structured clone algorithm and the >> == javascript operator. > > > Is that a problem? I can't see performance being an issue it has to > determine which type of '==' to use anyway, and JavaScript does not appear > to support Unboxing or Unboxed types. > > I accept that 2^53 bits is enough. > > To me though there is an advantage in not having the ID as an integer type. > Basically the ID is an unordered sequence type. The only valid operators are > '==' and '!='. ordered comparisons (greater, less) and maths mean nothing. I > would think it better to use an opaque type so that people do not mistakenly > think they can use these operators. It also allows implementers much more > flexibility (and optimisation potential) in how they actually implement the > IDs. > > > Cheers, > Keean. > > > >
Received on Saturday, 13 November 2010 11:22:35 UTC