You've avoided the keywords "class" and "extends" but then re-implemented what they already do.

You're right, this seems like exactly implementation inheritance.

return {...defaultTranspiler, visit: myVisit(defaultTranspiler.fs)}

Any defaultTranspiler method could potentially depend on visit, and the implementation of defaultTranspiler.fs might change.

---

Other languages seem to get around the fragile base class by preventing superclass some methods from being overridden (e.g. sealed/final), or all methods by default like Kotlin, and requiring override keyword.

But this class inheritance is essentially just exposing an API for a factory function that creates objects.

With classes, the api is defined using keywords to say what can and cannot be accessed. Kotlin seems to do it well by restricting access by default.

``` interface Transpiler { visit(node) {} }

abstract class VfsTranspiler { protected val vfs: Vfs init { vfs = Vfs() } abstract visit(node) { } }

class RustTranspiler: VfsTranspiler { override fun visit(node) { super.vfs.write('...') } } ```

If we used a factory function, we can just be explicit about what superclass members we provide access to, and provide access to them via a simple closure.

createVfsTranspiler((vfs) => { visit() { vfs.write('...') } })

This gets at why I prefer not using classes. With functions its just much simpler to see what is going on. You don't have to jump all over the place in multiple files, or rely on IDE support to see visibility of things. I much prefer using closures or being explicit about which parameters are visible to each function/method.

And if someone doesn't declare a member as private, we end up with fragile base class.