<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body ocsi="x">
<p>For some reason, my email quoting is not working correctly. Sorry<br>
<br>
________________________________________<br>
From: Jason Kraftcheck [kraftche@cae.wisc.edu].</p>
<font face="times new roman"></font>
<p><br>
Sent: Tuesday, August 24, 2010 11:27 AM<br>
To: Miller, Mark C.<br>
Cc: tstt-interface<br>
Subject: Re: proposals for enumeration of interface-specific error codes<br>
<br>
On 08/24/2010 12:24 PM, Jason Kraftcheck wrote:<br>
> On 08/24/2010 12:15 PM, Miller, Mark C. wrote:<br>
>>><br>
>>> kraftche@cae.wisc.edu wrote:<br>
>><br>
>><br>
>>> Further, the cosmetic factors are significant in this case. It would be<br>
>>> unnecessarily difficult and error prone for a user of the interface to<br>
>>> determine what subset of the error codes they expect to need to deal<br>
>>> with if they are an interleaved mess.<br>
>><br>
>> Oh, come on. grep iMesh_ iBase.h will give me the list just fine.<br>
>><br>
><br>
> Perphaps. But why require (even trivial) processing when it is also<br>
> trivial to group them in the header, making the whole thing more<br>
> self-documented.</p>
<p><font face="times new roman"></font> </p>
<p><font face="times new roman">Well, grouping implies offsetting which leads to (larger) sparse arrays than necessary. So, I don't see it as that trivial. And, by the way, this smells a whole like like implementation driving interface which I think sets a
bad precedent. So, wherever this 'requirement' is coming from, I'll raise the issue that I challenge that it 'must be' part of the interface specification.</font></p>
<p><br>
><br>
<br>
Also, the expected errors in that case will be:<br>
grep \(iMesh_\|iBase_\) iBase.h<br>
<br>
and the 'iBase_' part will match a lot more than just error codes.</p>
<p><font face="times new roman"></font> </p>
<p><font face="times new roman">Fair enough. But now that I think about it, I am not sure we actually have specified in the current spec. that the actual numerical values for these codes cannot change with new releases of the spec. and implementations. Therefore,
I think it is possible to both GROUP the codes by interface name as well as PACK them tightly in array index space.</font></p>
<p><br>
<br>
- jason</p>
</body>
</html>