<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 8:48 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="gmail_quote"><div class="im">On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <span dir="ltr"><<a href="mailto:stephen@pairhome.net" target="_blank">stephen@pairhome.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><br></div></div></blockquote></div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div> I can see a potential need in cases where a body of code is designed to interface with some already present service (for example, a phone dialer application designed to use an AddressBook service). But, in such a system, you wouldn't want to allow monkey patching anyway out of security concerns (if you could override the AddressBook interface, your code could potentially access information that the owner didn't want your code to access).</div>
</div></blockquote><div><br></div></div><div>But how do you override your own AddressBook? Bringing a new one into existence is one thing, but modifying your fully-populated one implemented by someone else is another thing altogether. If the system is so architected then it is presumably trivial to create a new instance, move the data across and replace the old with the new. But if the system isn't (e.g. for security or ip concerns) then you can't. But these issues operate at a higher level than the language/module/update level right? The issues with monkey patching are to do with keeping software maintainable and comprehensible to software authors. The issues of mutable extensible systems also involve their users, and that's more than I can think about right now :)</div>
</div></blockquote><div><br></div><div>Overriding your own AddressBook would be a problem of loading in new code and migrating the instances (pretty much like software works today where you load a new version of an application and it has to update your existing database(s)). So, the new code would have whatever fancy new stuff you wanted to do in your AddressBook, but for external applications like the phone dialer to be able to interact with it, it would still need support some defined (and ideally versioned) interface. To the degree that new versions of the phone dialer and the address book are backward compatible with the versions of the interface they support, you are free to upgrade each independently. And, the AddressBook is free to use some highly customized collections framework while the phone dialer uses an entirely different implementation of collections. Such a system would offer very significant benefits to a community like squeak. Imagine being able to able to run squeak 2.0 and squeak 3.10 concurrently (with them able to communicate with each other) and imagine all the old, abandoned, but still useful projects that could be readily used without the need to migrate them to all the latest version of your favorite fork. I don't see these issues as being at some higher level, I see the language and platform as lacking a much needed capability.</div>
<div><br></div><div>(btw, none of this necessarily implies everything must be in a single process, I imagine much of this could be accomplished using hydra for instance)</div><div><br></div><div>- Stephen</div></div>