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 Tue, 20 Oct 2009 13:54:52 GMT
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

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