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 Mon, 12 Oct 2009 10:51:21 GMT
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/


Mime
View raw message