<br><br><div class="gmail_quote">On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <span dir="ltr"><<a href="mailto:andreas.raab@gmx.de">andreas.raab@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Eliot Miranda wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Arguably not. (BTW VW has had it from 98). The crucial difference is that<br>
in VW an extension can be in more than one package. In Squeak a selector can only be in a single Monticello extension category. That leads to the awful bug that when an MC package patches a base selector to extend it to fix a bug it ends up in the package and its membership of the package it was in previously being lost. I understand that with method history this situation can be detected but if you e.g. condense changes then that history is lost, and the base package selector becomes only an extension Ouch.<br>
</blockquote>
<br></div>
That's a bug in condenseChanges, not a conceptual problem. BTW, I really fail to see how it would make any difference whatsoever if extension methods are in multiple packages or not. In either case you are *completely* screwed if you have multiple packages trying to extend the same method. Seriously, has there ever been a situation where that actually works? (my personal preference is actually that MC should blow up straight into your face if you try to change a method that's in an extension category already, but that's just me - I generally avoid extensions like the plague)</blockquote>
<div><br></div><div>I don't avoid extensions, and personally feel extensions are a core part of building frameworks. If objects are to interact they must provide protocol to support that interaction. In adding a new framework to an existing system this means extending existing objects so that they can interact with the new framework. Yes, one can do this badly, but there are lots of examples where this makes sense.</div>
<div><br></div><div>As far as patching, we've had this conversation before. I agree that a well-designed system will provide extension mechanisms that make patching unnecessary. But unless the designer has excellent foresight (which is more difficult the further forward in time one projects) then there will be areas of the system which have to be patched. If two packages need to patch the same method then there is a problem, but one is not totally screwed. Provided that both packages have the same patch then they are compatible. That means that one can load package A and get the patch, load package B and get the patch and load bth packages and get the patch provided it is identical in both packages. Seems fine to me, and much more desirable than requiring extra-package management of the patch (e.g. "please file-in this changeset before loading the package") because that extra-package stuff will get lost, or ignored and then you're screwed too.</div>
<div><br></div><div>So for me handling extensions in packages in robust ways is about the system pragmatically supporting real practice, rather than enforcing ideals which one should strive for but are costly to arrive at and must be evolved towards in practice.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The VW "solution" is OK as far as it goes; a package is a set of class, selector pairs (more than this, but this is the essence). An MC package is defined by class and method categories. VW's parcels are intensional, MC packages are extensional. <br>
</blockquote>
<br></div>
I don't understand the distinction you are making between intensional and extensional. Care to elaborate?</blockquote><div><br></div><div>I hope I've got this the right way round. An extensional concept is one where a rule selects the members, e.g. the set of all sets is an extentionally defined set. An intentional concept is where individual members are defined as such, so A labrador is a dog is an intentional definition. MC packages are extensional; the methods on a class in a category of the package are all the methods on the class that are not otherwise categorised in category extensions of other packages and whose history does not include a non-extension category. VW parcels are intentional; the methods in a parcel are those that are explicitly listed in the parcel. A parcel has a Dictionary of class to set of selector for each class with methods in the parcel.</div>
<div><br></div><div>I think its clear that the extensional approach is more convenient and provides a nicer UI because (especially in MC's use of the existing categorisation scheme) it dovetails with the existing programming facilities. It is tedious to have to add a method to a package every time one defines one. An extensional approach allows the adding to be implicit. 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). So I would argue for the physical implementation of a package, and an extension mechanism ot be intentional, but for the UI to be extensional, so that e.g. when one is in a particular project all methods get added to the project's current package without programmer intervention. One still needs additional tools that allow interacting with the intentional nature of things (much like the change set browser allows in moving changes between sets), but largely one can have one's cake and eat it too if the UI i extensional but packages are intentional.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">MC internally actually uses a set of class and selector pairs as well, it just derives them via PackageInfo from categories. And it most certainly can have methods in multiple packages. For example, if you add a method in category '*Foo-Bar-Baz' it will be part of the packages 'Foo-Bar-Baz', 'Foo-Bar' and 'Foo' (if those exist).</blockquote>
<div><br></div><div>No it doesn't. The list is an internal representation used merely in recording the set of methods in question. But that set is compyted by an extensional approach by applying a category pattern to the system as it exists currently and writing that projection of the rule out.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The only thing that prevents you from having other combinations of multiple package memberships is that there is no UI that allows you to specify which combinations of packages a method should be part of. The category hack is great because it works with existing tools, but existing tools don't allow for methods in multiple categories. If you fix that you get your multiple package membership in Monticello for free. Alternatively provide a UI to specify which other packages the method should be part of, and you're there, too.</blockquote>
<div><br></div><div>Agreed. But internally MC packages should specify an exact set of entities, and not rely on an extensional projection. It is imprecise and hence inherently buggy. (I am being very anal today ;).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
<br>
Cheers,<br><font color="#888888">
- Andreas<br>
<br>
</font></blockquote></div><br>