[coyotos-dev] IDL compatibility

[Charles Landau]

At 10:44 PM -0400 7/9/07, Jonathan S. Shapiro wrote:
>On Mon, 2007-07-09 at 14:07 -0700, Charles Landau wrote:
>>  While we're on the subject of IDL, and now that MarkM is back, I'd
>>  like to reopen this discussion by posing some questions.
>
>I have already answered Charlie's questions, but let me do so again.
>
>>  1. Is it possible to have more than one name for the same method?
>
>Yes. There are three ways to do this:
>
>   A. The bad way: add a second declaration with a matching signature
>      and assign it the same method code point as the first one.
>
>      This should not be allowed to work. Future versions of CapIDL
>      will enforce the "no overlapping code points" rule.

I don't think any versions of CapIDL have ever allowed you to assign 
the method code. I agree that for robustness you don't want users 
specifying method codes.

>   B. The less bad way: add a second declaration with a matching
>      signature, and treat the two method code points identically in
>      the server.

That's fine if you have control over the server. That might not be 
the case in my example b (the Francophonic user). And there is the 
extra branch (see below).

>  > It is desireable to have more than one name, for several reasons.
>>  a. You come up with better names. For example, you decide
>>  "CreateWidget" is preferable to "MakeWidget". You want to add the new
>  > name, but retain the old for compatibility.
>
>This is not a good justification for renaming a method, because it is
>not a good justification for breaking a source-level contract.

In a later message you explained why this does not break the contract.

>  > c. You rename something ("eros" to "capros", just to take a random
>>  example). You want to add the new name, but retain the old for
>>  compatibility.
>
>This case, I think, reveals Charlie's real focus. I'm pretty sure this
>is a bad idea, but since Charlie hasn't articulated what his higher
>level objective actually is, it is difficult to respond sensibly.

The higher-level objective is to respond to your request that the 
system I am developing based on the EROS code be called something 
other than EROS. I want to retain the old names containing "eros" for 
compatibility during the (possibly long) transition period.

The solution here is probably to use a tool like sed to reduce the 
length of the transition period to zero.

>   3. One less case in a switch statement that is dispatching on
>      cryptographically assigned identifiers.
>
>      On average, this will save exactly one branch instruction
>      in the switch dispatch sieve. It isn't worth it.

It appears we've switched sides on this issue. In your message at 
http://sourceforge.net/mailarchive/message.php?msg_name=1183234315.15542.21.camel%40vmx.eros-os.org, 
you argued that one branch instruction in the space bank alone was 
critical.

Actually, if I'm changing the root name from "eros" to "capros", all 
the names change, so the number of branches doubles.