Hi everyone.
While creating a bootstrap for Traits and 3.9a, I have with the following problem: Traits change the way methods are added. To do this, it adds some methods, lets say addMethod: and basicAddMethod: where the former calls the latter. Problem: when MC loads the former before loading the latter, it is then not able to load the latter, because method loading is now broken.
(Such an image is a pretty frustrating place to find ones self, since doits are methods)
So I can probably solve my little problem by loading a sequence of MC versions which slowly add things in the right order. OTOH, this could "just work" if the methods happened to load in the correct order.
Of course the "right order" does not always exist, for example mutually recursive methods. Of course when it exists, it can often not be found (since we generally have no idea what method a message send resolves to). OTOH, most of the time the order doesn't matter that much.
On the gripping hand (for me at least), when the load order does matter, it creates a lot of pain, and it seems like a simple heuristic would solve most such problems.
So - how do people here feel about MC ordering method additions topologically, so that A>>sel1 comes no sooner than B>>sel2 if A>>sel1 sends the selector sel2, at least when such an order exists?
Daniel
On Sep 28, 2005, at 4:50 PM, Daniel Vainsencher wrote:
So - how do people here feel about MC ordering method additions topologically, so that A>>sel1 comes no sooner than B>>sel2 if A>>sel1 sends the selector sel2, at least when such an order exists?
Certainly doesn't bother me; it can't be any worse than the current approach, and in the rare case it might even be better :) However, I wonder about the implementation: presumably you have to compile all the methods (without loading them) before you can do the analysis required for that. Once you're splitting up compiling and loading, how hard would it be to do something closer to an atomic load, where you swap in entire method dictionaries in a single message send... ?
Avi
packages@lists.squeakfoundation.org