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:22:00 +0000
Message-ID: <AANLkTi=gjfCwj-+h-LQZxrdWd3sdLk-c48_KnckmEsyQ@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>
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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:13 UTC