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, 13 Oct 2009 08:18:15 GMT
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/
>
>


-- 
Steve

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