Composing Software: An Introduction
Eric Elliott

I agree 20000000% with the above. Particularly with composing via this and the associated chaining, that work allows interesting, perhaps sneaky socket propping which is interesting and encourages a particular type of speed in code composition. That said, I am too much the novice to understand the compositional complexity of class, super, Object.defineProperty (function), multiple Object.defineProperties(this, {someObject, w/composed getters objects and their hidden methods returned… I dont know if this getter method approach is a language accident that I am exploiting and it will go away, but it allows heavy composition and multiple inheritance, meaning, Object.defineProperties(object, {parentObj{get:function(){return {method:()=>{return lots of stuff}, method2:()=>{return lots of stuff called method 2}, etc.}

This approach also grants a seeming true level of privacy and passing of multiple args to gets and sets…. Again, I have no idea if it’s intended, will stay in the language, or is just a dirty hack I stumbled upon. That said, I stumble upon its semantics only by repeatedly watching videos of the language’s author from 2009–2011, and these semantic accidents accorded with my best understanding of the language high level design. What is the best way to compose Objects, and object factories in this language. Mix-ins, classes and super-classes I simply cannot accept as the efficient, or even useful semantics for this prototype language. I just can do it way more efficiently with with a rube literal, so how do we compose? Functions expose, nakedly.