[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-29 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15533213#comment-15533213
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/29/16 4:58 PM:
---

even though limit( n ) is a stream thing, we don't need to implement it that 
way.  So we have a choice.


was (Author: schor):
even though limit(n) is a stream thing, we don't need to implement it that way. 
 So we have a choice.

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-21 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509972#comment-15509972
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/21/16 2:27 PM:
---

startAt(annoFS) for me is defined as an iterator moveTo(annotFS).  This moves 
to the left-most FS in the index that's >= (according to the index's 
comparator).

There's an ambiguity in startAt(annoFS).shift(1) and following(annoFS), because 
annoFS might be or might not be in the index.  If it was in the index, then 
shift(1) would be needed to match following().  If it was not in the index, the 
position is already at the following() spot, and shifting one more would miss 
an annotation.

This complexity can be encapsulated in the following() method.


was (Author: schor):
There's an ambiguity in startAt(annoFS).shift(1) and following(annoFS), because 
annoFS might be or might not be in the index.  If it was in the index, then 
shift(1) would be needed to match following().  If it was not in the index, the 
position is already at the following() spot, and shifting one more would miss 
an annotation.

This complexity can be encapsulated in the following() method.

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-21 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15509972#comment-15509972
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/21/16 2:02 PM:
---

There's an ambiguity in startAt(annoFS).shift(1) and following(annoFS), because 
annoFS might be or might not be in the index.  If it was in the index, then 
shift(1) would be needed to match following().  If it was not in the index, the 
position is already at the following() spot, and shifting one more would miss 
an annotation.

This complexity can be encapsulated in the following() method.


was (Author: schor):
There's an ambiguity here, because annoFS might be or might not be in the 
index.  If it was in the index, then shift(1) would be needed to match 
following().  If it was not in the index, the position is already at the 
following() spot, and shifting one more would miss an annotation.

This complexity can be encapsulated in the following() method.

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-21 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507873#comment-15507873
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/21/16 1:40 PM:
---

I think the general case is startAt(annotFS).shift( n ).  For the oft-used 
desire to start following some annoFS, it's fine to have "following(annoFS)" as 
a convenience method.  


was (Author: schor):
I think the general case is startAt(annotFS).shift(n).  For the oft-used desire 
to start following some annoFS, it's fine to have "following(annoFS)" as a 
convenience method.  

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507769#comment-15507769
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 8:57 PM:
---

My point was: can we have a signature variant for cas.select("pkg.MyJCasType") 
that allows the caller to provide at least a minimal type bound, e.g. 
`cas.select("pkg.MyJCasType", Annotation.class)`?... or should we infer the 
type for the variable to which the value is assigned... or really just use 
FeatureStructure as the result type?


was (Author: rec):
My point was: can we have a signature variant for cas.select("pkg.MyJCasType") 
that allows the caller to provide at least a minimal type bound, e.g. 
`cas.select("pkg.MyJCasType", Annotation.class)`?

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15507753#comment-15507753
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 8:50 PM:
---

I see how at first breaking up the API into these separate methods saves 
implementing various method signatures - but since we are going to introduce 
them again anyway with the "convenience methods with positional args", I don't 
see the benefit. If you like this model of implementation, I would suggest to 
implement it but keep the methods private and expose only the convenience 
methods in the API... maybe some "third-party" feedback might also provide 
additional new perspectives. Anybody?


was (Author: rec):
I see how at first breaking up the API into these separate methods saves 
implementing various method signatures - but since we are going to introduce 
them again anyway with the "convenience methods with positional args", I don't 
see the benefit. If like this model of implementation, I would suggest to 
implement it but keep the methods private and expose only the convenience 
methods in the API... maybe some "third-party" feedback might also provide 
additional new perspectives. Anybody?

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506927#comment-15506927
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 3:47 PM:
---

I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object, e.g

{noformat}
 SelectFS type(Class jcasClass_dot_class);
{noformat}


was (Author: rec):
I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object, e.g

{noformat}
  type(Class jcasClass_dot_class);
{noformat}

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506927#comment-15506927
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 3:51 PM:
---

I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object. We also need to chain the return type through the API.

{noformat}
 SelectFSs type(Class 
jcasClass_dot_class);
{noformat}



was (Author: rec):
I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object. We also need to chain the return type through the API.

{noformat}
 SelectFSs type(Class jcasClass_dot_class);
{noformat}



> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506927#comment-15506927
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 3:50 PM:
---

I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object. We also need to chain the return type through the API.

{noformat}
 SelectFS type(Class jcasClass_dot_class);
{noformat}




was (Author: rec):
I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object, e.g

{noformat}
 SelectFS type(Class jcasClass_dot_class);
{noformat}

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506927#comment-15506927
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 3:50 PM:
---

I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object. We also need to chain the return type through the API.

{noformat}
 SelectFSs type(Class jcasClass_dot_class);
{noformat}




was (Author: rec):
I assume we still have TOP in UV3? Then IMHO the generics should be bounded by 
that and not by object. We also need to chain the return type through the API.

{noformat}
 SelectFS type(Class jcasClass_dot_class);
{noformat}



> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Richard Eckart de Castilho (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506921#comment-15506921
 ] 

Richard Eckart de Castilho edited comment on UIMA-5115 at 9/20/16 3:46 PM:
---

I think methods that require offsets should not take `FeatureStructure` but 
require `AnnotationFS`, e.g.

{noformat}
SelectFSs at(AnnotationFS fs);  // AI
SelectFSs between(AnnotationFS fs1, AnnotationFS fs2);  // AI
{noformat}


was (Author: rec):
I think methods that require offsets should not take `FeatureStructure` but 
require `AnnotationFS`, e.g.

{noformat}
+  SelectFSs at(FeatureStructure fs);  // AI
+  SelectFSs between(FeatureStructure fs1, FeatureStructure fs2);  // AI
{noformat}

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-20 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15506523#comment-15506523
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/20/16 1:41 PM:
---

I didn't follow the example get().get().  I think the first get() would return 
the single element or null, and the 2nd get would not compile (since FS doesn't 
have a "get" method.  

The small value in Optional (seems "documentational", only, to me) is 
outweighed (IMHO) by it's verbosity and inefficiency (creating an extra Java 
object wrapping things).  But I certainly could be missing something...

The single(true), single(false) forms communicate less to the reader than 
singleOrNull and single.  Other forms which might communicate well include 
nullOk().single() or allowNull().single().  But that seems somewhat stilted.  
It might be useful if there are other methods where sometimes null is OK and 
other times you want to throw an exception.


was (Author: schor):
I didn't follow the example get().get().  I think the first get() would return 
the single element or null, and the 2nd get would not compile (since FS doesn't 
have a "get" method.  

The small value in Optional (seems "documentational", only, to me) is 
outweighed (IMHO) by it's verbosity and inefficiency (creating an extra Java 
object wrapping things).  But I certainly could be missing something...

The single(true), single(false) forms communicate less to the reader than 
singleOrNull and single.  Other forms which might communicate well include 
nullOk().single().  But that seems somewhat stilted.  It might be useful if 
there are other methods where sometimes null is OK and other times you want to 
throw an exception.

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-19 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504781#comment-15504781
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/19/16 9:47 PM:
---

Does uimaFIT iteration for coveredBy(fs1) filter the result by the type of fs1? 
 That is, if fs1's begin and end specify 10 FSs, but only 3 of them are of the 
type/subtype of fs1, does the result only have those 3 FSs?  I don't believe 
UIMA's subiterator design does this filtering - it just uses the fs1 for bounds 
and for type priority ordering (not type/subtype filtering).  It would seem 
this is not needed - could be covered by just selecting the type wanted 
already, ahead in the select spec, etc.


was (Author: schor):
Does uimaFIT iteration for coveredBy(fs1) filter the result by the type of fs1? 
 That is, if fs1's begin and end specify 10 FSs, but only 3 of them are of the 
type/subtype of fs1, does the result only have those 3 FSs?  I don't believe 
UIMA's subiterator design does this filtering - it just uses the fs1 for bounds 
and for type priority ordering (not type/subtype filtering).

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (UIMA-5115) uv3 select() api for iterators and streams over CAS contents

2016-09-19 Thread Marshall Schor (JIRA)

[ 
https://issues.apache.org/jira/browse/UIMA-5115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15504694#comment-15504694
 ] 

Marshall Schor edited comment on UIMA-5115 at 9/19/16 9:17 PM:
---

For UIMA-3724 and UIMA-3234, maybe use 3 methods:
* get() gets the single element or null
* single() gets the single element, throws if null or more than 1
* singleOrNull() gets the single element, returns null if no elements, throws 
if more than 1



was (Author: schor):
related feature requests to consider

> uv3 select() api for iterators and streams over CAS contents
> 
>
> Key: UIMA-5115
> URL: https://issues.apache.org/jira/browse/UIMA-5115
> Project: UIMA
>  Issue Type: New Feature
>  Components: Core Java Framework
>Reporter: Marshall Schor
>Priority: Minor
> Fix For: 3.0.0SDKexp
>
>
> Design and implement a select() API based on uimaFIT's select, integrated 
> well with Java 8 concepts.  Initial discussions in UIMA-1524.  Wiki with 
> diagram: https://cwiki.apache.org/confluence/display/UIMA/UV3+Iterator+support



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)