iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]
James Porter
jvporter at wisc.edu
Thu Oct 28 16:19:06 CDT 2010
On Thu, 2010-10-28 at 15:58 -0500, Jason Kraftcheck wrote:
> On 10/28/2010 02:59 PM, James Porter wrote:
> > On Thu, 2010-10-28 at 03:12 -0400, seol at scorec.rpi.edu wrote:
> >
> >> 4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter & iRel_getEntArrSetIterArr
> >>
> >> CURRENT Relation Type: Ent, Set, Both (Ent&Set)
> >> NEW: Ent, Set, Both (Ent&Set), EntArr
> >
> > Assuming we end up agreeing that directly encoding one-to-many
> > relationships in iRel (instead of relying on iMesh/iGeom to give us this
> > though sets and/or iterators), I don't think this is a good way to go
> > about doing it as it's really just a hack to work around implementations
> > that don't support sets.
>
> An implementation could support sets w/out using them for iRel-type association.
True, but I doubt it would be a serious issue then. Adding "EntArr" as a
relation type is adding a *direct* one-to-many relationship (I'll talk
about this more below), and is essentially overloading the RelationType
enum to contain info about 1) what kind of thing you're relating (ents,
sets, or both), and 2) the cardinality of that relation.
Of course, "Both" is a little bit strange too...
> > A clearer and more general-purpose way to do
> > this would be to add another property representing the cardinality of
> > the relation, that is, one-to-one, one-to-many, and so on.
> ...
>
> Or we could implement it by creating the set underneath and then returning
> its contents. In fact, I thought that was already the behavior of some of
> the iRel function implementations in Lasso (e.g. getEntEntArrRelation.) Am
> I missing something fundamental about this proposal? How is the "EntArr"
> case really different than the "Set" one? Don't both effectively imply a
> one->many relationship?
That is what happens now, and it's part of why the behavior for
setEntEntArrRelation is bizarre. For instance, what happens when there's
no related set on the "Set" side? I think Tim and I agreed that it
should currently return an error, but this would be problematic for
people who don't want to work with sets.
Again, this argument is basically why I'm not endorsing my suggestion
(I'm ok with the status quo), but the main difference is that "Set"
provides an *indirect* one-to-many relationship, and "EntArr" provides a
*direct* one-to-many relationship. That is, in the "Set" case, you have
to go through getEntities to get to the "many". Currently, I think the
iRel spec is strongly oriented towards using one-to-one relations
interally (that's certainly how Lasso does it), with the one-to-many
relations being "emulated" by way of already-existing functionality
(sets) in iMesh/iGeom. Whether this is a good thing or not depends on
what you think of sets.
As I mentioned with setEntEntArrRelation, this does potentially change
some of the semantics of other functions. The main reason I wanted to
get rid of the non-one-to-one functions in iRel is because of this
behavior.
- Jim
More information about the tstt-interface
mailing list