incubator-kato-spec mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Poole <spoole...@googlemail.com>
Subject Re: Lists - not useful?
Date Wed, 21 Oct 2009 15:24:58 GMT
Agreed , or +1.   Done and dusted

On Wed, Oct 21, 2009 at 3:53 PM, Stuart Monteith <stukato@stoo.me.uk> wrote:

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


-- 
Steve

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message