<br><br><div><span class="gmail_quote">On 12 Mar 2007 23:53:15 +0100, <b class="gmail_sendername">Lex Spoon</b> <<a href="mailto:lex@lexspoon.org">lex@lexspoon.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>In practice, it has proven very valuable that Smalltalk modules are<br>allowed to modify the system classes. This is a dangerous thing to<br>do, of course, but I would really hate to handicap the above fine<br>packages just because of the *potential* for danger. Instead, we
<br>should admit that inter-module conflicts exist, and deal with<br>them head-on, as they happen....</blockquote><div><br><br>You can never be sure that whatever object you're working with does in fact have Object as a superclass. This is particularly relevant with my project (DPON): I'm capturing message sends to objects to implement remote objects.
<br></div><br></div>Also, it's a requirement in my remote code system that loading one module using whatever mechanism physically CANNOT start causing strange symptoms in other modules. . This is a basic security requirement. What I'll probably do is prevent modifications to core classes like Object and String.
<br><br>In my opinion, code not related to the functionality of a particular object (such as any of the morphic methods on Object) should not be there. It should be refactored so that it is in the classes relevant to what the code is trying to do. For example, Object>>asXML should really be something like XMLEncoder>>encodeObject:, where the implementation makes use of >>isKindOf: or >>canUnderstand:. It's a bit more verbose, but prevents inter-module conflicts and keeps your code where it is relevant.
<br><br>Michael.