You are viewing a plain text version of this content. The canonical link for it is here.
Posted to kato-spec@incubator.apache.org by Stuart Monteith <st...@stoo.me.uk> on 2009/10/09 10:36:19 UTC
Lists - not useful?
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);
}
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.
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/
Re: Lists - not useful?
Posted by Steve Poole <sp...@googlemail.com>.
Agreed , or +1. Done and dusted
On Wed, Oct 21, 2009 at 3:53 PM, Stuart Monteith <st...@stoo.me.uk> wrote:
> Hello,
>
>
> A1 - I would suggest zero indexed on the principle it surprises /me/ the
> least.
> It fits most naturally with the Java language, which is itself zero
> based,
> like any sensible programming language. We are also inspecting Java
> structures.
> If the caller has to consider add removing 1 from the indexes, then that
> is only
> going to cause more problems than it solves. Especially if you consider
> running queries
> against arrays.
>
> A2 - Definitely java.lang.IndexOutOfBoundsException.
>
>
> Steve Poole wrote:
>
>> 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:
>>>
>>> >-8 Snip!
>>>
>>>
> --
> Stuart Monteith
> http://blog.stoo.me.uk/
>
>
--
Steve
Re: Lists - not useful?
Posted by Stuart Monteith <st...@stoo.me.uk>.
Hello,
A1 - I would suggest zero indexed on the principle it surprises /me/ the
least.
It fits most naturally with the Java language, which is itself zero
based,
like any sensible programming language. We are also inspecting Java
structures.
If the caller has to consider add removing 1 from the indexes, then
that is only
going to cause more problems than it solves. Especially if you
consider running queries
against arrays.
A2 - Definitely java.lang.IndexOutOfBoundsException.
Steve Poole wrote:
> 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 <sp...@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 <st...@stoo.me.uk>wrote:
>>
>> >-8 Snip!
>>
--
Stuart Monteith
http://blog.stoo.me.uk/
Re: Lists - not useful?
Posted by Steve Poole <sp...@googlemail.com>.
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 <sp...@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 <st...@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 <st...@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
Re: Lists - not useful?
Posted by Steve Poole <sp...@googlemail.com>.
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 <st...@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 <st...@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
Re: Lists - not useful?
Posted by Stuart Monteith <st...@stoo.me.uk>.
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 <st...@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 <st...@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/
Re: Lists - not useful?
Posted by Steve Poole <sp...@googlemail.com>.
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 <st...@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 <st...@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
Re: Lists - not useful?
Posted by Stuart Monteith <st...@stoo.me.uk>.
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 <st...@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/
Re: Lists - not useful?
Posted by Steve Poole <sp...@googlemail.com>.
I agree with most of this but have a couple of comments ...
On Fri, Oct 9, 2009 at 11:36 AM, Stuart Monteith <st...@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)
>
> 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
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/
>
>
--
Steve