W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2010

Re: [Bug 11270] New: Interaction between in-line keys and key generators

From: Keean Schupke <keean@fry-it.com>
Date: Sat, 13 Nov 2010 11:13:59 +0000
Message-ID: <AANLkTik6NjXPu8Ame2kZ0LFMn+XkGFFb_fWFob4A8Y8e@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Jeremy Orlow <jorlow@chromium.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Pablo Castro <Pablo.Castro@microsoft.com>, "public-webapps@w3.org" <public-webapps@w3.org>
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:14:35 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:42 GMT