On Jul 19, 2010, at 1:06 PM, Jason Kraftcheck wrote:
Mark Beall wrote:
Would it make sense for an implementation to define a value that means NULL (for here and other places that it could be of use)?
Well, what value would you choose and how would you guarantee that it wouldn't be problematic for any existing implementation? Zero would clearly be troubling for an implementation that was array-based and simply used array indices as handles.
There could be a function that returns that value (iMesh_getNullSet) or a global that the implementation must initialize to that value.
Passing the root set here could be confusing ("ah I see, everything is always added to the root set since I always have to pass it here. Oh wait, sometimes I don't have to pass it here, does that mean that this entity won't be added to the root set?")
I think this was one of the reasons that Tim argued that the function accept any set in the serial case. It would be less confusing than documenting a special case where an app need always pass the same redundant value (when working in serial.)
The problem with accepting any set is that you don't want people to use it for some other purpose in serial and then find they have to change their code to do the right thing in parallel.
I suppose we could pass a pointer to the handle, such that the pointer could be NULL. I'm not sure that that would be any less confusing than using the root set, through. And we already use the root set handle in exactly the same way in iMesh_loadMesh.
I'd say that using the root set to mean both "no set" and "the set that contains everything" is confusing. In iMesh_loadMesh (and most other places I saw when I looked quickly) you can say that it means "everything in the instance", which is the same as the root set. However if there are places (now or in the future) where there is a meaningful difference between the two things, that usage could become problematic. mark