Discussion:
Java devo: replacement for Iterable
(too old to reply)
Jim Sermersheim
2007-03-07 19:59:37 UTC
Permalink
So, our beloved Iterable<someType> way of doing things must die and be replaced by something else. What do people prefer:

1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.

#1 and #2 both have the problem of requiring IdAS consumers to cast the java.lang.Object(s) coming out of the iterators to the correct java types.

#3 has the problem of us having to define a lot of new interfaces, and dealing with the maintenance nightmares that come with decisions to change apis.

Jim
Jim Sermersheim
2007-03-07 21:55:10 UTC
Permalink
The fact that many (but perhaps not all) of the IdAS CPs use IdAS to present data that exists in some real store tends to throw a wrench into simplistic methods of performing updates (adds and modifies specifically).

I keep trying to shift APIs around in ways that would allow us to re-use things like IDigitalSubject, IAttribute, etc. when adding new subjects and modifying existing ones. One problem always surfaces: In re-using a single interface, and in keeping things simple, it complicates the CP writer's job by forcing the CP to have to keep track of whether an objects represents something in the real store, versus something that's being built up to be later added to the real store. Furthermore, some of the methods make no sense until the object has been added to the real store.

So, I'm wondering if taking a slightly different approach would be better. Here's what I'm thinking:

1) Remove IContext.addSubject, preserve (but pare down IContext.createSubject) createSubject always creates and adds a new subject. It takes as arguments the components of a subject (cuid, attributes, metadata). The return value is the resulting cuid, not an IDigitalSubject. This means we wouldn't have ambiguous husks of IDigitalSubject floating around.

2) Remove add and create methods from IHasAttributes and IHasMetadata. This removes confusion as to what happens when these are called on IDigitalSubject.

3) Because of #2, we have two needs: a) Need a way to build attributes and metadata to pass to the createSubject in #1, and b) Need a way to modify the attributes or metadata of an existing subject.

3.a) Add createAttribute and createMetadata methods to IAttributeModel and IMetadataModel (this is currently missing btw). These methods would be capable of creating an IAttribute or IMetadata which can be passed to createSubject. Similar methods would also be introduced to help build Filter assertions.

3.b) Introduce an UpdateSet class which is a set of UpdateOperation classes. An UpdateOperation class consists of an operation (Add, Delete, Replace), and one or more attribute or metadata values. This allows one to represent a set of modifications like: {Delete hatSize (8), Add hatSize (9), Delete favoriteCigaretteBrand, Replace favoriteDrinks (martini, cape cod)}
Jim Sermersheim
2007-03-08 07:37:55 UTC
Permalink
The javadoc at http://www.eclipse.org/higgins/org.eclipse.higgins.docs/idas/ reflects 1, 2, and 3.b. I marked methods that would go away as deprecated (all can be seen here http://www.eclipse.org/higgins/org.eclipse.higgins.docs/idas/deprecated-list.html). If I have time, I'll do 3.a tomorrow and followup with some sample code of how some different things would work.

Jim
The fact that many (but perhaps not all) of the IdAS CPs use IdAS to present data that exists in some real store tends to throw a wrench into simplistic methods of performing updates (adds and modifies specifically).

I keep trying to shift APIs around in ways that would allow us to re-use things like IDigitalSubject, IAttribute, etc. when adding new subjects and modifying existing ones. One problem always surfaces: In re-using a single interface, and in keeping things simple, it complicates the CP writer's job by forcing the CP to have to keep track of whether an objects represents something in the real store, versus something that's being built up to be later added to the real store. Furthermore, some of the methods make no sense until the object has been added to the real store.

So, I'm wondering if taking a slightly different approach would be better. Here's what I'm thinking:

1) Remove IContext.addSubject, preserve (but pare down IContext.createSubject) createSubject always creates and adds a new subject. It takes as arguments the components of a subject (cuid, attributes, metadata). The return value is the resulting cuid, not an IDigitalSubject. This means we wouldn't have ambiguous husks of IDigitalSubject floating around.

2) Remove add and create methods from IHasAttributes and IHasMetadata. This removes confusion as to what happens when these are called on IDigitalSubject.

3) Because of #2, we have two needs: a) Need a way to build attributes and metadata to pass to the createSubject in #1, and b) Need a way to modify the attributes or metadata of an existing subject.

3.a) Add createAttribute and createMetadata methods to IAttributeModel and IMetadataModel (this is currently missing btw). These methods would be capable of creating an IAttribute or IMetadata which can be passed to createSubject. Similar methods would also be introduced to help build Filter assertions.

3.b) Introduce an UpdateSet class which is a set of UpdateOperation classes. An UpdateOperation class consists of an operation (Add, Delete, Replace), and one or more attribute or metadata values. This allows one to represent a set of modifications like: {Delete hatSize (8), Add hatSize (9), Delete favoriteCigaretteBrand, Replace favoriteDrinks (martini, cape cod)}
Duane Buss
2007-03-07 22:28:03 UTC
Permalink
I personally think #1 is the simplest and appears to meet all of our needs.


Duane
From: "Jim Sermersheim" <***@novell.com>
To:<higgins-***@eclipse.org>
Date: 3/7/2007 1:26 PM
Subject: [higgins-dev] Java devo: replacement for Iterable
So, our beloved Iterable<someType> way of doing things must die and be replaced by something else. What do people prefer:

1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.

#1 and #2 both have the problem of requiring IdAS consumers to cast the java.lang.Object(s) coming out of the iterators to the correct java types.

#3 has the problem of us having to define a lot of new interfaces, and dealing with the maintenance nightmares that come with decisions to change apis.

Jim
Tom Doman
2007-03-08 01:46:05 UTC
Permalink
+1
I personally think #1 is the simplest and appears to meet all of our needs.


Duane
From: "Jim Sermersheim" <***@novell.com>
To:<higgins-***@eclipse.org>
Date: 3/7/2007 1:26 PM
Subject: [higgins-dev] Java devo: replacement for Iterable
So, our beloved Iterable<someType> way of doing things must die and be replaced by something else. What do people prefer:

1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.

#1 and #2 both have the problem of requiring IdAS consumers to cast the java.lang.Object(s) coming out of the iterators to the correct java types.

#3 has the problem of us having to define a lot of new interfaces, and dealing with the maintenance nightmares that come with decisions to change apis.

Jim
Michael McIntosh
2007-03-08 02:10:19 UTC
Permalink
+3 ;-)
Post by Duane Buss
+1
I personally think #1 is the simplest and appears to meet all of
ourneeds.
Post by Duane Buss
Duane
Date: 3/7/2007 1:26 PM
Subject: [higgins-dev] Java devo: replacement for Iterable
So, our beloved Iterable<someType> way of doing things must die and
1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.
#1 and #2 both have the problem of requiring IdAS consumers to cast
the java.lang.Object(s) coming out of the iterators to the correct java
types.
Post by Duane Buss
#3 has the problem of us having to define a lot of new interfaces,
and dealing with the maintenance nightmares that come with decisions
to change apis.
Jim
_______________________________________________
higgins-dev mailing list
https://dev.eclipse.org/mailman/listinfo/higgins-dev
Jim Sermersheim
2007-03-08 06:26:19 UTC
Permalink
um, me not so clever... you're saying you count for three people, or you like #3?
+3 ;-)
Post by Duane Buss
+1
I personally think #1 is the simplest and appears to meet all of
ourneeds.
Post by Duane Buss
Duane
Date: 3/7/2007 1:26 PM
Subject: [higgins-dev] Java devo: replacement for Iterable
So, our beloved Iterable<someType> way of doing things must die and
1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.
#1 and #2 both have the problem of requiring IdAS consumers to cast
the java.lang.Object(s) coming out of the iterators to the correct java
types.
Post by Duane Buss
#3 has the problem of us having to define a lot of new interfaces,
and dealing with the maintenance nightmares that come with decisions
to change apis.
Jim
_______________________________________________
higgins-dev mailing list
https://dev.eclipse.org/mailman/listinfo/higgins-dev
Michael McIntosh
2007-03-08 16:33:53 UTC
Permalink
I am saying third plus one to Iterable
Post by Jim Sermersheim
um, me not so clever... you're saying you count for three people, or
you like #3?
+3 ;-)
Post by Duane Buss
+1
I personally think #1 is the simplest and appears to meet all of
ourneeds.
Post by Duane Buss
Duane
Date: 3/7/2007 1:26 PM
Subject: [higgins-dev] Java devo: replacement for Iterable
So, our beloved Iterable<someType> way of doing things must die and
1) Use java.lang.Iterator
2) Use java.util.Enumeration
3) Build our own iterator interfaces.
#1 and #2 both have the problem of requiring IdAS consumers to cast
the java.lang.Object(s) coming out of the iterators to the correct
java
Post by Jim Sermersheim
types.
Post by Duane Buss
#3 has the problem of us having to define a lot of new interfaces,
and dealing with the maintenance nightmares that come with decisions
to change apis.
Jim
_______________________________________________
higgins-dev mailing list
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
https://dev.eclipse.org/mailman/listinfo/higgins-dev
_______________________________________________
higgins-dev mailing list
https://dev.eclipse.org/mailman/listinfo/higgins-dev
Loading...