[reSIProcate] A few upgrades to the API.

Alan Hawrylyshen alan at jasomi.com
Wed Jul 28 14:23:53 CDT 2004


Comments inline.

On Jul 28, 2004, at 12:29, david Butcher wrote:
[snip]
>> 2) an API compatibility call that returns an interger <= (V) that
>> indicates the cut-off point for behavioural
>>     or semantic compatibiliy.
>
> What does this mean? How does the API designate semantics?
> Example, please?
>

Say you check in a change that alters the way in which the library deals
with a function parameter that COULD cause grief to someone expecting 
the
old behaviour.  For example, and this is contrived, you invert the 
sense of
a boolean parameter.  The code still compiles, but the behaviour isn't 
what you'd
expect.  The compatibility # would be advanced so clients knew they 
were 'too old'
to expect reasonable results from the library.

Alan writes:
>> 3) Some typedefs to the SdpContents class [snip]

David Responds:
> I'm all for typedefs. Let's not get into the bathrobe and bullhorn 
> thing
> again, though. Also, hiding type is not necessarily an improvement. 
> Fine
> if all the caller can do is iterate. Seems to hinge on what we expect
> the caller to do with the datatype. Which mostly amounts to
> meta-discussion. I am not a heavy user of SdpContents, so will stop
> here.

We are -- and it seems silly to have multiple points defining these 
types. It might be sufficient to assert (contractually) that these 
items ARE associative access containers (or whatever) from the STL and 
follow the interface contract thereof. This is useful and means that 
you, as a client, can do things with confidence and not worry about 
things breaking if the implementation gets a tweak. Similarly, if this 
DID change, you could reset the compatibility-int and you'd at least 
have a clue before your code failed miserably.

As for the bullhorn / bathroom thing -- are you confusing me with Adam? 
I'm lost, and my bathrobe is usually not the same colour as RMS's.



Alan

a l a n a t j a s o m i d o t c o m




More information about the resiprocate-devel mailing list