On Tue, Jun 30, 2009 at 11:37 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Eliot Miranda wrote:
>
>> Arguably not.  (BTW VW has had it from 98).  The crucial difference is
>> that
>> 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.
>>
>
> 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)


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.

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.

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.

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.
>>
>
> I don't understand the distinction you are making between intensional and
> extensional. Care to elaborate?


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.

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.


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).


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.


> 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.


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 ;).



>
>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090630/258f78de/attachment.htm