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 14:18:26 GMT
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:
>
>> Hi,
>>   My thoughts were that it was cumulative - and it would be a permanent
>> effect.
>> Otherwise it would be applied to the results it was originally run
>> against, which would
>> mean keeping two sets of results.
>>
>> iterator - if the underlying results were to be closed I would expect a
>> DiagnosticException
>> , or something like that. This is like java.sql.ResultSet throwing an
>> SQLException if it was closed.
>>
>> Regards,
>>   Stuart
>>
>>
>>
>> Steve Poole wrote:
>>
>>> More thoughts
>>>
>>> applyfilter -  is that permanent and cumulative or  transitive and
>>> removable?
>>> iterator  - what happens when you change the filter or close the
>>> ResultSet?
>>>
>>>
>>> On Mon, Oct 12, 2009 at 11:51 AM, Stuart Monteith <stukato@stoo.me.uk
>>> >wrote:
>>>
>>>
>>>
>>>> Hi,
>>>>
>>>>
>>>> Steve Poole wrote:
>>>>
>>>>
>>>>
>>>>> I  agree with most of this but have a couple of comments ...
>>>>>
>>>>>
>>>>> On Fri, Oct 9, 2009 at 11:36 AM, Stuart Monteith <stukato@stoo.me.uk>
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Hello,
>>>>>>  Steve and I have been discussing what to do about lists.
>>>>>>
>>>>>> The issues I have with lists are:
>>>>>>
>>>>>> 1. They provide far more operations that are useful to us, or are
>>>>>> desirable
>>>>>> for us to implement.
>>>>>> For example:
>>>>>>      . any method that modifies a list.
>>>>>>      .
>>>>>> 2. The indices aren't useful. Usually knowing that an object is the
>>>>>> nth
>>>>>> object in the List is of no consequence - that relationship to it's
>>>>>> peers
>>>>>> is
>>>>>> normally not terribly important. What is important is the ID of the
>>>>>> object
>>>>>> and being able to retrieve that object by its ID.
>>>>>>   3. As well as IDs, there are other attributes to search on.
>>>>>>
>>>>>> For instance,
>>>>>> Here are my initial thoughts:
>>>>>>
>>>>>> public interface JavaRuntime {
>>>>>>      ResultSet<JavaObject> getAllObjects();
>>>>>>      ResultSet<JavaClass> getAllClasses();
>>>>>>
>>>>>> }
>>>>>>
>>>>>> public interface ResultSet<T> {
>>>>>>      // Return a subset of type <T> based on the "filter" string
>>>>>>      // an XPath query.
>>>>>>      ResultSet<T> filterSet(String filter);
>>>>>>
>>>>>>      // Reduce this result set using the filter passed.
>>>>>>      void applyFilter(String filter);
>>>>>>
>>>>>>      // Return an iterator over the        Iterator<T> iterate();
>>>>>>
>>>>>>      // Run a query on the string.
>>>>>>      ResultSet<?> query(String filter);
>>>>>> }
>>>>>>
>>>>>>   Need a close or dispose method to allow the associated resources
>>>>>> (which
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> could be in a database ) to be freed.   We need to have the idiom set
>>>>> so
>>>>> that the consumer knows they have to do the releasing.
>>>>>
>>>>> Is ResultSet the right name?    It's what you get from JDBC and
>>>>> programmers
>>>>> using JDBC will "get" the concept.   However I think its too close and
>>>>> we
>>>>> should consider something else.   how about QueryResult or QuerySet
>>>>> (remember unlike a database this data is readonly)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Yes, I neglected to include the "close" method, which is important if we
>>>> were to have a database backend to the API.
>>>> We should differentiate from JDBC. If nothing else, it could confuse
>>>> implementations that use JDBC.
>>>> The English language only has so many synonyms for this kind of thing.
>>>> Perhaps to make this unique to our API we can
>>>> call them "DiagnosticResult".
>>>> Set is obviously not quite right, as we don't want to have set
>>>> semantics,
>>>> "collection" is unspecific.
>>>>
>>>>
>>>>  Using this you could do:
>>>>
>>>>
>>>>>      ResultSet<JavaObject> objs = runtime.getAllObjects();
>>>>>>      ResultSet<JavaObject> strings =
>>>>>> objs.filterSet("@class[name='java/lang/String']");
>>>>>>
>>>>>> To retrieve all of the objects that are instances of String.
>>>>>>
>>>>>> Alternatively, you could do:
>>>>>>
>>>>>>      ResultSet<JavaObject> strings =
>>>>>>
>>>>>> runtime.getAllObjects().applyFilter("@class[name='java/lang/String']");
>>>>>>
>>>>>> The strings could then be iterated over using the iterator:
>>>>>>      for(JavaObject string : strings.iterator()) {
>>>>>>              string.doStuff();
>>>>>>      }
>>>>>>
>>>>>> The filters, I would expect, would have two axes.
>>>>>>
>>>>>> For objects:
>>>>>>      a/b - b would be a field
>>>>>>      a@b - b would be an attribute we've added.
>>>>>>              . class - the object's class
>>>>>>              . superclass - the object's superclass.
>>>>>>
>>>>>> For classes:
>>>>>>      a/b - b would be a static field
>>>>>>      a@b - b would be an attribute of the class.
>>>>>>
>>>>>> For arrays:
>>>>>>      a@b - b would be an attribute
>>>>>>      a[10] - would be the tenth element.
>>>>>>
>>>>>>
>>>>>> Of course, while a filter is useful, I don't think it's entirely
>>>>>> appropriate to use XPath, which is more appropriate for querying.
>>>>>>
>>>>>> We could look at the XQuery equivalent as a guide  -    that has
>>>>>> support
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> for what is called "FLWOR"  http://en.wikipedia.org/wiki/FLWOR
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Looks interesting - I'll have to absorb it.
>>>>
>>>>
>>>>  Of course, you lose type safety, which is to be expected as a query is
>>>> in
>>>>
>>>>
>>>>>
>>>>>
>>>>>> just a string.
>>>>>>
>>>>>> For example, to return all of the classes that are strings (in an
odd
>>>>>> and
>>>>>> artifical manner):
>>>>>>      ResultSet<JavaObject> objs = runtime.getAllObjects();
>>>>>>
>>>>>>      ResultSet<JavaClass> stringClasses =
>>>>>> objs.query("[@class/name='java/lang/String']");
>>>>>>
>>>>>> Of course, the question is, how many JavaClasses would be in the
>>>>>> result
>>>>>> set? There should be only one in a given runtime.
>>>>>>
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Stuart Monteith
>>>>>> http://blog.stoo.me.uk/
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Stuart Monteith
>>>> http://blog.stoo.me.uk/
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>> --
>> Stuart Monteith
>> http://blog.stoo.me.uk/
>>
>>
>
>
> --
> Steve
>



-- 
Steve

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