Standard Object Semantic Compatibility

Class Date Class SetDate method setDate(day: Integer; callmethod writeDate(day: Integer; month: Integer; month: Integer;

year: Integer); year: Integer); method getDate(); callmethod readDate();

EndClass EndClass The methods tagged with the callmethod keyword are part of the REQUIRES of the class; those tagged with the method keyword are part of the PROVIDES part. These classes are not type compatible since their outbound and inbound interfaces are of two different types (DateType and some new type; lets call it AnotherDateType). If the only difference between the methods setDate and writeDate is exactly their syntax, then these classes are semantically compatible.

This mapping exists because both of these classes realize the same kind, that of DATE. We know this fact because at some point a developer defined this ontology by virtue of a claim or a belief on the classes.

Such a truth structure could have been defined explicitly through the specification of a semantic property (realizes) on the classes, via manipulation in the development environment, or by direct input with the kind

system. Now, because Date: DATE, then a mapping exists from each of its parts (e.g., the setDate method) to each of the parts of the kind (the canonical SETDATE kind feature). These maps, when used in composition, define a simple renaming (sort of an alpha-renaming for instances)

for the classes. We can realize such a renaming either by directly manipulating the source text (if this is permissible in the current context), or by generating a simple wrapper class automatically. Thus, an adapter which maps calls from writeDate to setDate and from readDate to getDate will allow

the composition of these two classes to perform correctly.