{"id":5904,"date":"2024-06-27T17:18:50","date_gmt":"2024-06-27T15:18:50","guid":{"rendered":"https:\/\/oopm.org\/?page_id=5904"},"modified":"2024-11-26T14:36:30","modified_gmt":"2024-11-26T13:36:30","slug":"printable-an-interface-like-aspect","status":"publish","type":"page","link":"https:\/\/oopm.org\/?page_id=5904","title":{"rendered":"18.2 Interface-like aspects"},"content":{"rendered":"
\"image_pdf\"<\/a>\"image_print\"<\/a><\/div>\n

The addressable aspect in the previous section was an example of a general aspect with both data-items and methods.<\/p>\n\n\n\n

The following example illustrates aspects that only have methods. In other languages this kind of aspects are defined by a special interface<\/em> definition, but we will define also these kinds of aspects by means of classes. Usually interface only have method signatures, i.e. name, parameters and return type, while aspects used for interface may have methods with more than signatures.<\/p>\n\n\n\n

We start out by the simple aspect of being printable:<\/p>\n\n\n\n

class<\/strong> printable:\n   print:<  \n      inner(print)<\/code><\/pre>\n\n\n\n
Different classes of objects may have a printable<\/code> aspect. Here we define that Person<\/code> objects are printable:<\/p>\n\n\n\n
class<\/strong> Person(name: var<\/strong> String):\n   asPrintable: obj<\/strong> Printable\n      print::\n         name.print<\/code><\/pre>\n\n\n\n
Because the description of asPrintable<\/code> is nested within Person<\/code>, the data item name<\/code> of Person<\/code> is visible, and it is therefore possible to extend print to print the name<\/code>.<\/p>\n\n\n\n
A Person<\/code> object are printed like this:<\/p>\n\n\n\n
JohnSmith: ref<\/strong> Person\nJohnSmith := Person(\"John Smith\")\n...\nJohnSmith.asPrintable.print<\/code><\/pre>\n\n\n\n
This will not surprisingly print “John Smith”. A more interesting example is the case where we have a set of Person<\/code> objects and apply asPrintable.print<\/code> to all of objects in this set:<\/p>\n\n\n\n
persons: obj<\/strong> Set(Person)\n-- insert Person objects in this set, e.g.:\npersons.insert(Person(\"John Smith\"))\npersons.insert(Person(\"Liza Jones\"))\npersons.insert(Person(\"Mary Pole\"))\n...\npersons.scan\n   current.asPrintable.print<\/code><\/pre>\n\n\n\n
The same effect could<\/em> have been obtained by defining Person<\/code> as a subclass of Printable<\/code>, but that would classify Person<\/code> to be Printable<\/code>, and that is not<\/em> what we want to express. Subclassing works well for classification, but for aspects we typically would like to have that a class like Person<\/code> can have more than one aspect.<\/p>\n\n\n\n
Suppose we also have the notion of being movable:<\/p>\n\n\n\n
class<\/strong> Movable: \n   move(newAddr: ref<\/strong> Address):\n      inner(move)\n<\/code><\/pre>\n\n\n\n
then Person<\/code> could also be movable:<\/p>\n\n\n\n
class<\/strong> Address:\n   -\"-\n   print:<\n      -\"-\n\nclass<\/strong> Person(name: var<\/strong> String): \n   addr: obj<\/strong> Address\n\n   asPrintable: obj<\/strong> Printable\n      print::\n         name.print\n         address.print\n\n   asMovable: obj<\/strong> Movable\n      move::\n         addr.change(newAddr)<\/code><\/pre>\n\n\n\n
With the above class definitions, the properties of Printable<\/code> (in this case just the method print<\/code>) is also a property of Person<\/code>, although via the name asPrintable<\/code>. Correspondingly for move <\/mark><\/code>of Movable<\/code>:<\/p>\n\n\n\n
Joe: ref<\/strong> Person\n...\nJoe := Person(\"Joe\")\nJoe.asPrintable.print\nJoe.asMovable.move(Address(\"Norway\",\"Oslo\",\"R\u00f8ahagan\", 33)) <\/code><\/pre>\n\n\n\n
As mentioned, the above aspects, Printable<\/code> and Movable<\/code>, are example of interfaces in other languages, with only methods. As the methods print<\/code> and move<\/code> are defined independently of Person<\/code> (or other classes that should be Printable<\/code> and Movable<\/code>, interfaces usually do not have any statements describing their actions. This is not the case for aspects that work as interfaces.<\/p>\n\n\n\n
<\/p>\n
\n\t\t<\/a>\n\t\t<\/div>","protected":false},"excerpt":{"rendered":"
The addressable aspect in the previous section was an example of a general aspect with both data-items and methods. The following example illustrates aspects that only have methods. In other languages this kind of aspects are defined by a special interface definition, but we will define also these kinds of aspects by means of classes. […]<\/p>\n","protected":false},"author":3,"featured_media":0,"parent":3511,"menu_order":2,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"class_list":["post-5904","page","type-page","status-publish","hentry"],"mb":[],"mfb_rest_fields":["title","gutenberg_elementor_mode"],"_links":{"self":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5904","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=5904"}],"version-history":[{"count":24,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5904\/revisions"}],"predecessor-version":[{"id":9881,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/5904\/revisions\/9881"}],"up":[{"embeddable":true,"href":"https:\/\/oopm.org\/index.php?rest_route=\/wp\/v2\/pages\/3511"}],"wp:attachment":[{"href":"https:\/\/oopm.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=5904"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}