incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Monteith <stuk...@stoo.me.uk>
Subject Re: Lists - not useful?
Date Wed, 21 Oct 2009 14:53:25 GMT
Hello,


A1 - I would suggest zero indexed on the principle it surprises /me/ the 
least.
     It fits most naturally with the Java language, which is itself zero 
based,
     like any sensible programming language. We are also inspecting Java 
structures.
     If the caller has to consider add removing 1 from the indexes, then 
that is only
     going to cause more problems than it solves. Especially if you 
consider running queries
     against arrays.

A2 - Definitely java.lang.IndexOutOfBoundsException.

  

Steve Poole wrote:
> Thinking about the form of  the QueryResult some more (as I implement it)  a
> question occurs.
>
>
> for "T getElement(long elementNumber) throws IOException"
>
> Q1 -  Are we zero or one indexed?
> Q2 -  Qhat should we do for element numbers outside the range - perhaps
> throwing an ioexception is wrong -  maybe IndexOutofBounds as well?
>
>
> On Tue, Oct 20, 2009 at 2:54 PM, Steve Poole <spoole167@googlemail.com>wrote:
>
>   
>> I've been thinking about our "third" layer  which should provide a further
>> abstraction on top of the JavaRuntime. This abstraction is intended to hide
>> the parts of the runtime that really aren't of use to an application
>> programmer - like the multiple heaps for instance.     I've got the simple
>> beginnings of an implementation and I'll post more about that later.   What
>> I did notice ( and  why I'm on this thread)  is that whether we go with
>> Lists or a QueryResult on the API the both force the implementer to  cache
>> everything (which means we run out of memory quickly ) or implement
>> sophisticated mapping code.
>>
>>   I want to loose the Lists and I like the design pattern for the
>> QueryResult (in that the receiver has to dispose of it)  But I think that we
>> are asking too much of the QueryResult implementer to  support the filtering
>> options.
>>
>> So I think the right structure for the QueryResult is
>>
>> public interface QueryResult<T> extends Iterable<T>{
>>
>>     T getElement(long elementNumber) throws IOException;
>>
>>     long getSize() throws IOException;
>>
>>     void dispose() throws IOException;
>> }
>>
>> Note the extends Iterable   - that means that we get   for(X in
>> queryresultinstance)  for free!.
>>
>>
>>
>> On Tue, Oct 13, 2009 at 11:49 AM, Stuart Monteith <stukato@stoo.me.uk>wrote:
>>
>> >-8 Snip!
>>

-- 
Stuart Monteith
http://blog.stoo.me.uk/


Mime
View raw message