itaps-parallel Questions about iMeshP

[Mark Beall]

But, for people to actually write applications that use this  
interface, they need to know what they are allowed to do.

I keep seeing the phrase "implementation defined" being used to  
describe a lot of behavior. Maybe we are using different definitions  
of that phrase. If I'm writing code to some interface or spec and  
there is something described as "implementation defined" behavior what  
that means to me is "don't do this if you want your code to work with  
other implementations".

If the documentation stated something like:

"Entities are added and removed from parts using the following entity  
set functions:
- Add entity to part --> iMeshAddEntToSet
etc.
The behavior of any other entity set functions when used with a part  
is implementation defined"

Then it's been clearly stated that these functions must work and you  
shouldn't use any other entity set functions on parts if you are  
writing code that needs to work with other implementations.

mark

On Dec 18, 2009, at 12:02 PM, Tim Tautges wrote:

> Right, so clearly, some uses for sets have very specific and unique  
> semantics, and some of the functions which take sets as arguments  
> won't be allowed.  I think this can be handled at the implementation  
> level, and specialized based on the implementation.  If the iMesh  
> functions are used for querying such sets, the implementation is  
> already probably specialized for those sets; this just continues  
> that.  There are many examples of such things in both iGeom and  
> iMesh, e.g. construction of mesh entities from other mesh entities  
> (iMesh_createEnt).
>
> - tim
>
> Mark Beall wrote:
>> In reading things again, there is this bullet above the one I quoted:
>> - Many iMesh functions that accept an iBase_EntitySetHandle are  
>> also useful in the context of a iMeshP_PartHandle. These functions  
>> are reinterpreted so that they can accept either an  
>> iBase_EntitySetHandle or an iMeshP_PartHandle.
>> What, exactly, does this imply? My concern is that it means that a  
>> part has to behave as an entity set for a call like iMesh_addEntSet  
>> (which adds an entity set to an existing set). The semantics of an  
>> entity set say that, if I make this call, the entity set that I  
>> added would have to be returned if I subsequently called  
>> iMesh_getEntSets on that part.
>> I don't really see how an implementation that doesn't represent  
>> parts as entity sets could reasonably be expected to do this.
>> If the intention isn't to require the above to work that way, it  
>> would seem that it would be better to say that a part is a "read- 
>> only" entity set and that there be part-specific functions to add/ 
>> remove entities to/from a part. It seems to me that this would  
>> allow efficient implementations whether or not they are done using  
>> entity sets.
>> mark
>> On Dec 15, 2009, at 4:06 PM, Mark Beall wrote:
>
> -- 
> ================================================================
> "You will keep in perfect peace him whose mind is
>  steadfast, because he trusts in you."               Isaiah 26:3
>
>             Tim Tautges            Argonne National Laboratory
>         (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
>         phone: (608) 263-8485      1500 Engineering Dr.
>           fax: (608) 263-4499      Madison, WI 53706
>