craig at netjam.org
Thu May 25 05:07:54 UTC 2006
> 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.
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]
More information about the Squeak-dev