4 ms·
Thanks for taking a look Reg. Would you mind if I ran an idea past you? The other idea I'm toying with is something similar, but having immutable classes. So
by dhotson 16y ago
Thanks for taking a look Reg.
Would you mind if I ran an idea past you?
The other idea I'm toying with is something similar, but having immutable classes. So basically every time you add a new method, instead of modifying the class you would return a brand new class.
Crazy? :-)
- jerf 16y agoRunning through that in my head, that's basically equivalent to subclassing. At least, I can't find a difference. (In fact if you do it the naive way you'll end up with something less functional than subclassing for no good reason, so you might as well just treat it as a subclass.) It also blocks monkey patching the original class, which I observe neutrally.
- deleted 16y ago[deleted]
- raganwald 16y agoI think it call comes down to class resolution. So whether you call it subclassing, versioning, whatever, the interesting thing is when you say that this bird is a "Blackbird," how do we figure out which version of the class to use? Sometimes we want to take the existing Blackbird, add or change something, let's call it Blackbird2 internally. If we are creating and owning an object, it's a Blackbird2 in our scope obviously. But if we get handed a Blackbird from someone else, can we treat it as a Blackbird2 in our scope but it is still a Blackbird outside of our scope? That mechanism is really scoped class resolution or scoped behaviour resolution or something. It completely solves the clashing monkey patch problem. Anyhow, I guess what I'm saying is that the implementation of versions of classes is one thing, and the resolution of names or references to classes is another (and very interesting) thing.