Class Structure Hash - Revision history

Manus: Removed useless

2010-03-08T03:55:47Z

Removed useless <br/>

Clemahieu at 17:35, 5 March 2010

2010-03-05T17:35:01Z

Clemahieu: New page: Purpose: A request for comments on the notion of various equality tests for a class. The tests can be used in areas such as serialization, proxy/stub calls, versioning, dynamic type loadi...

2010-03-04T23:53:09Z

New page: Purpose: A request for comments on the notion of various equality tests for a class. The tests can be used in areas such as serialization, proxy/stub calls, versioning, dynamic type loadi...

New page

Purpose: A request for comments on the notion of various equality tests for a class. The tests can be used in areas such as serialization, proxy/stub calls, versioning, dynamic type loading, etc.

Hash value are a SHA256 hash

Class-text hash:
- Complete hash of the text of the class. Any change including non-processed areas such as `note' or comments would cause the hash value to change.

Semantic-text hash:
- Hash value of the semantically-meaningful text of the class. This would ignore the actual character contents of breaks and would ignore comments and note fields. If a buggy version of a class is discovered, it could be rejected for serialization or connection by this hash value.

Attribute hash:
- Hash value of the attributes of the class. This would essentially mean anything with an equal attribute hash could be deserialized/serialized without recovery.

Feature hash:
- Name, signature, and export hash for a feature

Interface-to-class hash:
- Hash value of feature names and signature exported to a specific class. This would be useful for remote proxying. A class would have a additional value for each class to which features are exported. If class A exports features to {ANY}, {A}, {B}, and {NONE} it would have a hash value for each to say whether the interface exported to either ANY, A, or B has changed. Changes to features exported to A would affect the hash code for {ANY} and {A} but not {B}. Changes to features exported to NONE would not affect any hash values.

Contract hash:
- A hash value for a the contract of a feature.

Interface-to-class contract hash:
- A hash value for the contract of all features exported to a class.

Additional issues:
- Mutual recursive references. In some cases two classes reference each other; this could lead to difficulty in creating a hash value for both.
- Some traditionally non-semantic areas such as `note' actually have semantic value.
- Are 256 bits needed? Maybe truncate hash to 128 bits or 64 bits.

@@ Line 1: / Line 1: @@
-'''Purpose:'''<br/>
+'''Purpose:'''
 A request for comments on the notion of various equality tests for a class.  The tests can be used in areas such as serialization, proxy/stub calls, versioning, dynamic type loading, etc.
 Hash value are a SHA256 hash
-'''Class-text hash:'''<br/>
+'''Class-text hash:'''
 * Complete hash of the text of the class.  Any change including non-processed areas such as `note' or comments would cause the hash value to change.
-'''Semantic-text hash:'''<br/>
+'''Semantic-text hash:'''
 * Hash value of the semantically-meaningful text of the class.  This would ignore the actual character contents of breaks and would ignore comments and note fields.  If a buggy version of a class is discovered, it could be rejected for serialization or connection by this hash value.
-'''Attribute hash:'''<br/>
+'''Attribute hash:'''
 * Hash value of the attributes of the class.  This would essentially mean anything with an equal attribute hash could be deserialized/serialized without recovery.
-'''Feature hash:'''<br/>
+'''Feature hash:'''
 * Name, signature, and export hash for a feature
-'''Interface-to-class hash:'''<br/>
+'''Interface-to-class hash:'''
 * Hash value of feature names and signature exported to a specific class.  This would be useful for remote proxying.  A class would have a additional value for each class to which features are exported.  If class A exports features to {ANY}, {A}, {B}, and {NONE} it would have a hash value for each to say whether the interface exported to either ANY, A, or B has changed.  Changes to features exported to A would affect the hash code for {ANY} and {A} but not {B}.  Changes to features exported to NONE would not affect any hash values.
-'''Contract hash:'''<br/>
+'''Contract hash:'''
 * A hash value for a the contract of a feature.
-'''Interface-to-class contract hash:'''<br/>
+'''Interface-to-class contract hash:'''
 * A hash value for the contract of all features exported to a class.
-'''Additional issues:'''<br/>
+'''Additional issues:'''
-* Mutual recursive references.  In some cases two classes reference each other; this could lead to difficulty in creating a hash value for both.<br/>
+* Mutual recursive references.  In some cases two classes reference each other; this could lead to difficulty in creating a hash value for both.
-* Some traditionally non-semantic areas such as `note' actually have semantic value.<br/>
+* Some traditionally non-semantic areas such as `note' actually have semantic value.
 * Are 256 bits needed?  Maybe truncate hash to 128 bits or 64 bits.