{"id":1351,"date":"2018-12-03T04:00:56","date_gmt":"2018-12-03T04:00:56","guid":{"rendered":"http:\/\/sdi.thoughtstorms.info\/?p=1351"},"modified":"2018-12-03T04:00:56","modified_gmt":"2018-12-03T04:00:56","slug":"extra-thoughts-on-assemblage-oriented-programming","status":"publish","type":"post","link":"https:\/\/sdi.thoughtstorms.info\/?p=1351","title":{"rendered":"Extra thoughts on "Assemblage" Oriented Programming"},"content":{"rendered":"

Brief followup thoughts on the previous article<\/a>. Read that first.
\nClasses?<\/strong>
\nClasses are really just techniques to help construct objects. In an “Assemblage” language the Assemblage or Pattern itself is the way you construct the objects. The grammar explains how to parse a plain EDN or JSON-like data-literal into the assemblage.
\nSo perhaps we don’t need classes in our Assemblage language.
\nInheritance?<\/strong>
\nMuch of the experience of the last four decades is that inheritance is almost more trouble than it’s worth. The “brittle base-class” problem etc. OO practice tends towards re-use through delegating to components, rather than inheritance.
\nAs Charles Scalfani says here<\/a>, in the real world, containment \/ ownership relationships are far more common and far easier to reason about and work with than class or type hierarchies.
\nSo why do OO languages emphasize, and provide special infrastructure resources to help with, inheritance hierarchies but not containment hierarchies?
\nGood question. The + sigil in my suggested Assemblage language is explicit language support for containment. Perhaps there could be more. And we can dispense with inheritance.
\nOur Assemblage language can use prototypes when something like inheritance is absolutely necessary.
\nModule boundaries<\/strong>
\nDefining module boundaries, loosening coupling at boundaries and data-hiding to prevent leakage of dependency through module boundaries are obviously good practices. But making each individual class a hard bounded module is a mistake. One of the pains of Java is that classes which are inevitably and rightly highly interdependent are obliged to be more stand-offish and formal with each other than they need to be.
\nIn Assemblage programming, the Assemblage is the natural module. An entire Assemblage would likely live within a single file. The brief, elegant grammatical description of the assemblage in a single place means that it’s easy to understand the structure of the assemblage and, if necessary, when changing it, to understand that change everywhere in the assemblage’s code.
\nSo it makes no sense to decouple objects within the assemblage from each other. Or to hide the details of the inner structure of one object in the assemblage from others in the same assemblage.
\nData hiding \/ privacy, if supported \/ enforced at all by the language, should be at the level of the assemblage and not the individual objects.
\nAt the same time, stricter, fine-grained control over mutability is more useful. Explicitly immutable fields within objects make data-hiding less of an issue as it’s impossible for other parts of the assemblage to make unexpected changes to it.<\/p>\n","protected":false},"excerpt":{"rendered":"

Brief followup thoughts on the previous article. Read that first. Classes? Classes are really just techniques to help construct objects. In an “Assemblage” language the Assemblage or Pattern itself is the way you construct the objects. The grammar explains how to parse a plain EDN or JSON-like data-literal into the assemblage. So perhaps we don’t […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4],"tags":[29,287,296,311],"class_list":["post-1351","post","type-post","status-publish","format-standard","hentry","category-opinion","tag-assemblage-programming","tag-modules","tag-mutability","tag-object-oriented"],"_links":{"self":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts\/1351","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1351"}],"version-history":[{"count":0,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=\/wp\/v2\/posts\/1351\/revisions"}],"wp:attachment":[{"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1351"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1351"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sdi.thoughtstorms.info\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1351"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}