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 Tue, 13 Oct 2009 10:49:53 GMT
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/


Mime
View raw message