Hi Andreas--
Modularity is one of those areas where theory goes only so far and having a practical example is really important to study real-life implications of the system. For example, personally I was (well, still am ;-) somewhat hesitant whether imprinting will be good enough to capture all the corner cases; the cases that happen "one in a thousand" (like a file not being there) and may require a set of methods that's not available at runtime (e.g., after imprinting). I'm curious - how do you deal with that issue in practice?
I liken that risk to the risk one takes in any application deployment. If you don't have sufficient test case coverage, bugs will slip through to users. Spoon can help automate the creation of the more common test cases, but the burden of being "complete enough to ship" is still upon the human developer, as it always has been. People have written tools to try to deduce what *might* happen when a system runs, but so far Spoon doesn't attempt anything along those lines.
...what does Spoon do to make [unconstrained class names] work?
(Please see my response to Chris.)
Without the files at the beginning aren't we risking that we basically arrive at some "fixed point" for each system that we can't leave without breaking things horribly?
Hmm, I don't think so. Can you give a concrete example?
How do you deal with this [overloaded method signatures]?
(Please see my response to Colin.)
This is very interesting, thanks a lot!
Sure thing! Thanks for the questions.
-C
spoon@lists.squeakfoundation.org