[Xapian-devel] GSoC xapian node binding thoughts
james-xapian at tartarus.org
Tue May 29 17:03:22 BST 2012
I'd say it's better than to refuse to compile, although it's somewhat moot right now. All numbers will overflow eventually, although I assume in Node yo'd just get IEEE rounding behaviour? Basically, there's no nice solution.
Slicing / comprehension I mean you return an object that will act as an array but which doesn't read out the data at that point. Obviously has interesting interactions with the async model of Node, but having to think about paging seems like a step back from nice abstractions to me :-(
On 29 May 2012, at 09:37, Liam <xapian at networkimprov.net> wrote:
> On Tue, May 29, 2012 at 12:32 AM, James Aylett <james-xapian at tartarus.org> wrote:
> I'd favour either complaining about overflow of numbers rather than types, or auto-convert to strings so it's a bit more like using twitter snowflake ids. Or I guess something like the math.Long trick from Closure.
> Isn't it poor form to work for a time and then overflow without warning? As for a workaround, I'd want to know how users need to manipulate doc ids in JS before choosing a hack...
> Any idea when v8 will get 64 bit support? Or is this not on the roadmap at all?
> They're under discussion for the next draft of the ECMA standard, I believe.
> On arrays, is there no way of deferring comprehension until later? So you could pass an array-like object around and slice it later.
> Comprehension? Slice? Sorry I've not run across those terms in this context.
> Once can define "getter" function members in an object or prototype (class); accessing the member implicitly invokes the function. However we wouldn't use that mechanism to perform I/O, as getters only function synchronously.
> Xapian-devel mailing list
> Xapian-devel at lists.xapian.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Xapian-devel