2 ms·

> In Self, it is legitimate to take an existing window, clone it, and change properties and methods to taste. The first window serves as prototype for the secon

> In Self, it is legitimate to take an existing window, clone it, and change properties and methods to taste. The first window serves as prototype for the second, despite also being a regular window. But doesn't this have the risk, that I change some property on the first window, without realising the second window is using the first as its prototype – and while that property change is beneficial for the first window, it is detrimental to the second? I suppose the same thing can happen in class-based OO – I might make some change to a superclass which is beneficial for one subclass but breaks another. However, I think the class-vs-instance dichotomy helps here – if I'm trying to evaluate whether a change to the superclass might break a subclass, I can focus on the subclasses, and often I can get away with not studying every piece of code which instantiates or uses the class and its subclasses. I can't use that heuristic in prototype-based languages, since the language syntax and semantics don't distinguish unextended uses from extensions. > It's also possible to use what I call the Master Mold pattern (after the Sentinel from Marvel Comics whose only purpose is to make more Sentinels). That is, to construct an object that isn't actually used except as a prototype for other objects. Oh sure, but here we are back to "weak-typing" vs "strong-typing". A class-based language enforces the "Master Mold" pattern, and if you try to violate it, your code won't even compile. A prototype-based language doesn't enforce the pattern, it is just in the programmer's head. Being able to break it in an exceptional case might be helpful; on the other hand, there is the risk the programmer might break it by accident rather than intention, producing bugs which would never happen in a more strongly-typed language.

bitwize 4y ago
> But doesn't this have the risk, that I change some property on the first window, without realising the second window is using the first as its prototype – and while that property change is beneficial for the first window, it is detrimental to the second? As I recall in Self, the two objects are independent of each other aside from the second being derived from the first upon its creation. Meaning changing one does not affect the other. "But what if you want to change something about both windows, or all windows derived from a prototype?" you might say. "You would have to change them all manually, for every single affected window!" To which I say the Self developers apparently thought the rigidity of class hierarchy and the fragile base class problem were bigger problems than the unergonomic nature of making sweeping changes across an entire set of derived objects. Class-based object systems present shortcomings because you cannot accurately predict a class hierarchy that will solve your problem especially if it is unknown. Even in a language as flexible as Smalltalk, class-hierarchy decisions made before a problem was fully characterized impeded the programmers' ability to fit a solution to the problem. OO developers have learned to accept these shortcomings, and the extra work it takes to work around them. Self is an experiment in eliminating these problems, and it just presents a different set of tradeoffs.

bitwize 4y ago

> But doesn't this have the risk, that I change some property on the first window, without realising the second window is using the first as its prototype – and while that property change is beneficial for the first window, it is detrimental to the second? As I recall in Self, the two objects are independent of each other aside from the second being derived from the first upon its creation. Meaning changing one does not affect the other. "But what if you want to change something about both windows, or all windows derived from a prototype?" you might say. "You would have to change them all manually, for every single affected window!" To which I say the Self developers apparently thought the rigidity of class hierarchy and the fragile base class problem were bigger problems than the unergonomic nature of making sweeping changes across an entire set of derived objects. Class-based object systems present shortcomings because you cannot accurately predict a class hierarchy that will solve your problem especially if it is unknown. Even in a language as flexible as Smalltalk, class-hierarchy decisions made before a problem was fully characterized impeded the programmers' ability to fit a solution to the problem. OO developers have learned to accept these shortcomings, and the extra work it takes to work around them. Self is an experiment in eliminating these problems, and it just presents a different set of tradeoffs.