[coyotos-dev] IDL compatibility

[Charles Landau]

At 12:22 PM -0400 6/19/07, Jonathan S. Shapiro wrote:
>On Tue, 2007-06-19 at 08:36 -0700, Charles Landau wrote:
>  > At 10:46 AM -0400 6/19/07, Jonathan S. Shapiro wrote:
>  > >Cryptographic code points are regrettable because they cannot be
>>  >efficiently demultiplexed. The problem with any *other* method code
>>  >synthesis scheme is that central coordination is required to avoid code
>>  >point collisions.
>>
>>  There are many schemes that could avoid collisions in a single chain
>>  of inheritance. You could have an easily-demultiplexed method index
>>  in the low bits, and (only for robustness, in case a method code is
>>  misused) a hash in the high bits.
>
>The current scheme is that the most-significant 8 bits encode the
>inheritance depth, with the "root" value being 1 (to guarantee
>non-collision with RC_OK). The least-significant 24 bits are the method
>number in order of appearance within the interface.
>
>This is not a good scheme. It is vulnerable to many innocuous edits that
>can cause method codes to be inadvertently altered. Unfortunately, I do
>not know of any implicit code point assignment strategy *other* than a
>pure hash on fully-qualified name (or reliably random generation) that
>does not share this issue.

How about:
- the most-significant 8 bits encode the inheritance depth, as now, and
- The least-significant 24 bits are the method number in alphabetical order

The alphabetical order will not change unless you add, delete, or 
rename a method, all of which are incompatible changes, not innocuous 
edits.