iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]

[Jason Kraftcheck]

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.

> 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.
> 
> Don't take the above suggestion as endorsement, though. As the
> maintainer of (currently) the only iRel implementation, I should note
> that doing this (either your way or mine) will significantly increase
> the complexity and decrease the potential for interoperability** of iRel
> unless the iMesh and iGeom specs are updated as well. In Lasso's case
> anyway, doing this interoperably would require variable-length tags (and
> possibly a way of serializing other implementations' handles).

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?


- jason