4 ms·
> If your superclass uses NSCopyObject, it’s now your problem just as much as if you’d used NSCopyObject directly, whether you like it or not. One of the more
by tempodox 2y ago
> If your superclass uses NSCopyObject, it’s now your problem just as much as if you’d used NSCopyObject directly, whether you like it or not.
One of the more insidious drawbacks of OOP: The tight coupling introduced by inheritance.
- derefr 2y agoAFAIK the pure platonic ideal of OOP (i.e. the thing that Smalltalk and Self do) makes no mention of subclassing — that’s bolted-on brain-damage that’s become conflated with OOP. The way a “real” OOP language would do subclassing, would just be composition: wrapping an instance of the “parent” and proxying messages up to it. If such a language wanted to “support inheritance in the language” (i.e. put syntax sugar around that wrapping), the result would probably look something like Golang’s anonymous embedded struct fields — where embedding a “parent” object of type X, gives your wrapping object Y default proxy methods to call the X instance’s methods of the same name; and default proxy getters/setters for the X instance’s fields; both of which you can override as you please / are implicitly shadowed by methods+fields of the same name declared on the wrapper type.
- deleted 2y ago[deleted]
- wahern 2y agoSmalltalk and Self use prototyping for inheritance, like JavaScript and Lua. It's a dynamically typed version of subclassing, where your parent is itself a live object, not just a definition. I suppose it's proxy-like, except forwarding of messages/method invocations is automatic and part of the language semantics, and the context object (self) is the one used in the caller's invocation. I've not used Objective C much, but I believe the core of Objective C works the same--non-overridden methods (message handlers) of an instantiated object are invoked using the parent prototype's instance definition. Objective C derives both it's semantics and technical jargon (e.g. selectors) straight from Smalltalk. But it also supports so-called protocols, aka interfaces in other languages, which because it's a more familiar paradigm seems to be how most people associate OOP with Objective C. I guess I'm making a hash of it, but in any event the end result is quite similar to if not largely indistinguishable from class inheritance. And because it's all dynamic, and depending on the language mechanics and your particular masochistic proclivities, it's even often quite straight forward to achieve multiple inheritance, e.g. in Smalltalk or Lua using a catch-all/fallback handler to select a method from a second (or third, fourth, etc) prototype subtree.
- pjmlp 2y agoSelf goes one step further, in Self to create new forms of objects, first one has to clone an existing object, add the required object structure to it, dynamically, and then use it as prototype for newer instances of that form. Additionally Self, in its original form while the Java vs Self vs Smalltalk wars were going at Sun, is a full single user workstation, only with the kernel code/JIT written in C++, everything else is Self. It is this kind of plasticity that provided the brewing ground for high performance JITs, that eventually found their way into JavaScript, and why the usual "Python is too dynamic" excuse, is just that, an excuse for not wanting to spend the engineering resources that Smalltalk and Self JITs have trailed.
- hayley-patton 2y agoSmalltalk is definitely class based, though you are right for Self. It's rather unrelated to types, though I see the analogy - that said some paper on statically-typed Wyvern mentioned adopting the Self model for delegation.
- igouy 2y ago"Smalltalk encourages well-factored designs through inheritance. Every class inherits behavior from its superclass … all forms of ordered collections in the system will instantly acquire this new capability through inheritance." 1981 "Design Principles Behind Smalltalk" Daniel H. H. Ingalls https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
- Sakos 2y agoApparently, the earliest versions of Smalltalk as designed by Alan Kay didn't have inheritance. It was only added later on, seemingly in the name of performance: > After significant revisions which froze some aspects of execution semantics to gain performance (by adopting a Simula-like class inheritance model of execution), Smalltalk-76 was created. This system had a development environment featuring most of the now familiar tools, including a class library code browser/editor. Smalltalk-80 added metaclasses, to help maintain the "everything is an object" (except variables) paradigm by associating properties and behavior with individual classes, and even primitives such as integer and Boolean values (for example, to support different ways to create instances). https://en.wikipedia.org/wiki/Smalltalk#History https://en.wikipedia.org/wiki/Smalltalk#History https://wiki.squeak.org/squeak/989 https://wiki.squeak.org/squeak/989
- igouy 2y agoIf you'd like to know about the early history of Smalltalk, then I'd recommend Alan Kay's "The Early History of Smalltalk" (in this case say pages 19-31) [pdf] https://web.archive.org/web/20230503050530/http://www.metaobject.com/papers/Smallhistory.pdf https://web.archive.org/web/20230503050530/http://www.metaob... "… since things can be done with a dynamic language that are difficult with a statically compiled one, I just decided to leave inheritance out as a feature in Smalltalk-72, knowing that we could simulate it back using Smalltalk's LISPlike flexibility. … By the time Smalltalk-76 came along, Dan Ingalls had come up with a scheme that was Simula-like in its semantics but could be incrementally changed on the fly to be in accord with our goals of close interaction." p31
- pjmlp 2y agoOnly for those that misunderstand OOP with inheritance, and never learned there are many forms of OOP.