<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 1:38 PM, Stephen Pair <span dir="ltr"><<a href="mailto:stephen@pairhome.net">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 class="im">On Tue, Jun 30, 2009 at 3:00 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div> But as I've said earlier in the thread the extensional approach has problems when it comes to managing multiple packages that can overlap (as I think s inevitable in imperfect complex systems). </div>
</div></blockquote><div><br></div></div><div>I realize this thread is more concerned with the here and the now, but doesn't this problem go away entirely in a system like Newspeak? When you can have modules of code co-resident and active at the same time, wouldn't you just create a new version of some package on which you depend rather than patch it with extension methods you define in your own package? Your code would happily use your version of the package while others happily use the unmodified version.</div>
</div></blockquote><div><br></div><div>In theory yes. But as soon as one had a living system which contained objects already active then I don't see how the Newspeak module system solves the problem. It neatly allows one to reuse modules and extend them locally. But as far as I can see once you want to interact in new ways with already live objects then one may still need to patch.</div>
<div><br></div><div>Gilad is virulently against monkey-patching and so there is no support for extensions in Newspeak modules; all very well. But at the same time one of the models of use for Newspeak is where clients implemented in Newspeak are orthogonally synchronised (both data and code are updated) at suitable points in an applications' use (e.g. when a server interaction is initiated). Here the author of a module is allowed to modify it and the next time any client containing an instance of that module would have the client's instance of the module updated transparently. So in a situation where some rich application on the client is composed of two modules, and the author of one of them wants an extension method added to the other so that his modifications can function one would have to request the author of the other module to add it and (presumably) wait for changes to propagate. There are lots of issues here (what if the author of the second module goes bust) but if the picture can be realised its actually much better than the Smalltalk package status quo because every instance is continuously integrated. One of the issues that gives rise to the need for patches is that one can't ask the author to update their package and so one has to do it oneself. Gilad's scheme is a great idea, but I'm not entirely sure it is that different from the current situation with automatically updated software (OSs etc). As the software gets more complex so organizations are less able to change it frequently. Newspeak may have some new means with which to attack the problem but the problem still remains.</div>
<div><br></div><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>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><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="gmail_quote"><div></div>
<div><br></div><font color="#888888"><div>- Stephen </div></font></div>
<br><br>
<br></blockquote></div><br>