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

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.
>
>
>
>