You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@etch.apache.org by Bo Hansen <md...@gmail.com> on 2011/07/15 13:47:09 UTC
Hash-code overlap check?
Hi,
I was wondering if any check is made at compile time to check if any of the
hash codes collide or is it up to the user to ensure this does not happen?
Thanks in advance,
Bo
Re: Hash-code overlap check?
Posted by scott comer <we...@mac.com>.
correct. there is a design for the solution of that problem, perhaps
you'd like to implement it?
the design is, don't ever delete methods or fields. Instead, use
something like @Retire or @Delete to disable them but preserve the name
and documentation in the code. and the compiler then has what it needs,
which is the name to prevent future collisions (with the same name or a
different name with the same hash).
this is more of an api design problem, anyway, not a technical one. you
have to design these apis carefully, and that means don't reuse names
ever, don't change the type of a name ever. a name represents a
"contract" with the callers and receivers for all time. the best way to
maintain the rules and history is to keep the name in the api but
deprecate or retire it.
scott out
On 7/19/2011 1:45 AM, Bo Hansen wrote:
> Ok, thanks. But in the rare case that you change an interface I guess
> it could ruin backwards compatibility.
> If you remove a field and add a new one it might potentially get the
> same ID, but no checks are able to catch it.
> Compared to Thrift they use an always incrementing ID in order to
> avoid the re-use problem. One can argue that
> the propability to write a previously used ID in thrift might be
> higher than a hash collision ;-).
> A solution could be to add a checking mechanism to compare all
> versions of .etch-files in a project.
>
> Best regards,
> Bo
>
> On Mon, Jul 18, 2011 at 6:22 PM, scott comer <wert1y@mac.com
> <ma...@mac.com>> wrote:
>
> martin, bo,
>
> that text is from the hash code impl.
>
> the compiler implements the test for collisions, and yes, there is
> one.
>
> scott out
>
>
> On 7/18/2011 8:47 AM, Martin Veith wrote:
>>
>> Hi Bo,
>>
>> I have taken a look into the Java runtime source code and found
>> the following text commenting the return value of the Hash
>> function used by Etch:
>>
>> “@return a hash of name in the unicode character encoding which is
>>
>> very likely to be unique over reasonable name spaces. Collisions
>>
>> should be very unlikely as they will force the user to
>> change the
>>
>> name.”
>>
>> So there is no check at compile time for a hash collision, but it
>> is very unlikely.
>>
>> Best regards
>>
>> Martin
>>
>> *From:*Bo Hansen [mailto:mdboha@gmail.com]
>> *Sent:* Freitag, 15. Juli 2011 13:47
>> *To:* etch-user@incubator.apache.org
>> <ma...@incubator.apache.org>
>> *Subject:* Hash-code overlap check?
>>
>> Hi,
>>
>> I was wondering if any check is made at compile time to check if
>> any of the hash codes collide or is it up to the user to ensure
>> this does not happen?
>>
>> Thanks in advance,
>> Bo
>>
>
>
Re: Hash-code overlap check?
Posted by Bo Hansen <md...@gmail.com>.
Ok, thanks. But in the rare case that you change an interface I guess it
could ruin backwards compatibility.
If you remove a field and add a new one it might potentially get the same
ID, but no checks are able to catch it.
Compared to Thrift they use an always incrementing ID in order to avoid the
re-use problem. One can argue that
the propability to write a previously used ID in thrift might be higher than
a hash collision ;-).
A solution could be to add a checking mechanism to compare all versions of
.etch-files in a project.
Best regards,
Bo
On Mon, Jul 18, 2011 at 6:22 PM, scott comer <we...@mac.com> wrote:
> **
> martin, bo,
>
> that text is from the hash code impl.
>
> the compiler implements the test for collisions, and yes, there is one.
>
> scott out
>
>
> On 7/18/2011 8:47 AM, Martin Veith wrote:
>
> Hi Bo,****
>
> ** **
>
> I have taken a look into the Java runtime source code and found the
> following text commenting the return value of the Hash function used by
> Etch:****
>
> “@return a hash of name in the unicode character encoding which is****
>
> very likely to be unique over reasonable name spaces. Collisions****
>
> should be very unlikely as they will force the user to change the****
>
> name.”****
>
> ** **
>
> So there is no check at compile time for a hash collision, but it is very
> unlikely. ****
>
> ** **
>
> Best regards****
>
> Martin****
>
> ** **
>
> ** **
>
> *From:* Bo Hansen [mailto:mdboha@gmail.com <md...@gmail.com>]
> *Sent:* Freitag, 15. Juli 2011 13:47
> *To:* etch-user@incubator.apache.org
> *Subject:* Hash-code overlap check?****
>
> ** **
>
> Hi,
>
> I was wondering if any check is made at compile time to check if any of the
> hash codes collide or is it up to the user to ensure this does not happen?
>
> Thanks in advance,
> Bo****
>
>
>
Re: Hash-code overlap check?
Posted by scott comer <we...@mac.com>.
martin, bo,
that text is from the hash code impl.
the compiler implements the test for collisions, and yes, there is one.
scott out
On 7/18/2011 8:47 AM, Martin Veith wrote:
>
> Hi Bo,
>
> I have taken a look into the Java runtime source code and found the
> following text commenting the return value of the Hash function used
> by Etch:
>
> "@return a hash of name in the unicode character encoding which is
>
> very likely to be unique over reasonable name spaces. Collisions
>
> should be very unlikely as they will force the user to change the
>
> name."
>
> So there is no check at compile time for a hash collision, but it is
> very unlikely.
>
> Best regards
>
> Martin
>
> *From:*Bo Hansen [mailto:mdboha@gmail.com]
> *Sent:* Freitag, 15. Juli 2011 13:47
> *To:* etch-user@incubator.apache.org
> *Subject:* Hash-code overlap check?
>
> Hi,
>
> I was wondering if any check is made at compile time to check if any
> of the hash codes collide or is it up to the user to ensure this does
> not happen?
>
> Thanks in advance,
> Bo
>
RE: Hash-code overlap check?
Posted by Martin Veith <Ma...@bmw-carit.de>.
Hi Bo,
I have taken a look into the Java runtime source code and found the following text commenting the return value of the Hash function used by Etch:
"@return a hash of name in the unicode character encoding which is
very likely to be unique over reasonable name spaces. Collisions
should be very unlikely as they will force the user to change the
name."
So there is no check at compile time for a hash collision, but it is very unlikely.
Best regards
Martin
From: Bo Hansen [mailto:mdboha@gmail.com]
Sent: Freitag, 15. Juli 2011 13:47
To: etch-user@incubator.apache.org
Subject: Hash-code overlap check?
Hi,
I was wondering if any check is made at compile time to check if any of the hash codes collide or is it up to the user to ensure this does not happen?
Thanks in advance,
Bo