create/destroy name change proposal

[seol at scorec.rpi.edu]

No objection to name change suggestions - actually more robust and
consistent API is welcome even though it means more work.

In terms of memory management, we do agree with Tim.

Seegyoung

> Echoing previous comments, I think:
> - it is worthwhile to adjust names for consistency, i.e. we should change:
> . remove -> destroy
> . new -> create (though I think the proper name should be
> iMesh_createMesh, not iMesh_create)
>
> - I don't think we should add an iMesh_addTag, because of the ambiguities
> with getting tags whose values have not been
> set (a comment in the header would be useful here, probably in the set
> function, to the effect that setting results in
> adding too)
>
> - I think we should allow apps to specialize on memory management, and the
> current API allows that well enough now
>
> - tim
>
> Jason Kraftcheck wrote:
>> Mark Miller wrote:
>>> Hi Mark,
>>>
>>> I like yours and Carl's comments on this storage issue. However, I also
>>> think that together you have arrived at what the specification should
>>> say regarding storage associated with things being removed or deleted.
>>> I
>>> think both you and Carl are saying that the whether storage is freed up
>>> on remove/destroy operations is left to the implementation.
>>>
>>> However, I also agree with your point that if iMesh_destroy (aka
>>> iMesh_dtor) did that, we'd be in a heap of trouble. So, the
>>> specification of iMesh_destroy should be that all memory associated
>>> with
>>> the iMesh instance be freed.
>>>
>>> But, now that I think about it, that raises another question having to
>>> do with how the functions are named. I kinda sorta had in mind that any
>>> operation with 'destroy' in the name also freed memory while 'remove'
>>> did NOT say one way or the other.
>>>
>>
>> I agree with your first to paragraphs.  Not so much with the later one.
>> All
>> this function renaming is for consistency seems a little excessive for
>> me.
>> While it would be nice to have consistent names, I just don't think it's
>> worth the API breakage..
>>
>> But as long as we're discussing API changes and memory issues I'd like
>> to
>> bring up a different issue that has bothered me for a while: the status
>> array passed back from iMesh_createEntArr.  I have two issues with this:
>> a)
>> it is quite inconvenient and of dubious value and b) it is rather
>> inconsistent from an API POV.
>>
>> What is the use case for this?  How many applications will truly check
>> the
>> array to see which individual entity creations failed?  Is it worth
>> having
>> every application remember to free this array as opposed to making that
>> <1%
>> of applications that care about per-entity success/failure do their
>> entity
>> creation one at a time?  Why not just have a flag selecting, for
>> implementations that do not allow duplicate entities, whether it should
>> return the handle for the existing entity or fail for duplicate
>> entities.
>>
>> As for b), I think that any function in the interface should free any
>> arrays
>> allocated during the call before returning failure.  This is possible
>> for
>> every function in the API except iMesh_createEntArr, which is required
>> to
>> return an array when it fails.
>>
>> - jason
>>
>
> --
> ================================================================
> "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
>
>