From: Ralph Johnson people don't generate selector names randomly. For example, Morphic adds #isMorph and #costumes to Object. It is possible that someone else might add #costumes to Object, but nobody would try to define #isMorph unless they were trying to cause trouble.
Consider an effort to construct a simpler Morphic (or refactor it). You might want exactly that behaviour during development of the new Morphic, where both the old and the new versions defined the same method on the same class with different implementations. You almost certainly *would* want it in a putative future image where MVC had gone, and hence the only toolset you could use to construct the new Morphic was running using features of the old Morphic.
Spoon+Naiad could resolve this in either of two ways, as I undertand it. One way would be to run the "new" Morphic in its own object memory and remote-debug it into existence; this is independent of namespaces. The other would be to allow both in the same image at the same time; this is hightly dependent on namespaces. Craig will no doubt tel me I'm talking through an inappropriate orifice here...
If we're planning on refactoring Squeak, we're going to come across instances like this. At present, one has to be very, very careful when changing some parts of the image, as it's very easy to break something and leave oneself without access to tools - this is the responsibility that comes with the power of being able to change anything 'live'. I'd love to see a way of reducing this danger, and I'm very interested that Craig appears to have provided us with two distinct ways - one of which we appear to be intent on removing from consideration!
- Peter
If we're planning on refactoring Squeak, we're going to come across instances like this. At present, one has to be very, very careful when changing some parts of the image, as it's very easy to break something and leave oneself without access to tools - this is the responsibility that comes with the power of being able to change anything 'live'. I'd love to see a way of reducing this danger, and I'm very interested that Craig appears to have provided us with two distinct ways - one of which we appear to be intent on removing from consideration!
- Peter
I think this is exactly why the approach of using two images is better. With Spoon I can change the target image as needed to get it from the "old" state to the "new" state without it needing to be functional in support of tools or even a UI. If you tried to refactor Morphic in-place the risk to functioning UI would be too great. I see no need for a module system to attempt to address this problem, as the Spoon approach will always be far better.
A good argument can be made to always use two images. Image 1 is always tools, and image 2 is always domain objects.
Michael
Hi Peter--
One way would be to run the "new" Morphic in its own object memory and remote-debug it into existence; this is independent of namespaces. The other would be to allow both in the same image at the same time; this is highly dependent on namespaces. Craig will no doubt tell me I'm talking through an inappropriate orifice here...
Hee. :) Actually, in the second case you could install the core of Naiad, which among other things allows every class to have an arbitrary name (and create modules, and transfer them elsewhere). I don't think namespaces would ever be necessary in either case.
-C
squeak-dev@lists.squeakfoundation.org