Avi Bryant <avi.bryant at gmail.com> writes:

> On Fri, 25 Mar 2005 18:57:24 +0100, Samir Saidani
> <saidani at info.unicaen.fr> wrote:

>> extension methods : this is methods extending the instance side of a
>> current class
>> 
>> extension classes : this is methods extending the side class of a
>> current class
>
> I'm not sure which method you're thinking of, but that's not what
> #extensionClasses does.  It returns a list of the classes that are
> extended by the current package, which is to say, all of the classes
> for the methods in #extensionMethods.

Thansk avi, that's right, I thought about extensionClasses, and
thought that there was a difference between class and instance
extension, but no. So

extension methods : this is methods *extending* a current class
 
extension classes (extendedClasses is more correct no ?) : this is
classes *extended* by a package. extensionClasses should be classes
*extending* a current package (what I have in mind to do).

>> In a same way, I propose the following convention :
>> 
>> Collections-Unordered-*SqueakEnh-Collections
>> 
>> (or *<ModifyingPackage>-<Section>-<PackageName>-<Section> but for
>> browser displaying categories in alphabetic order, the other one would
>> be more convenient)
>
> Apart from the issue of alphabetic order, I don't see what the point
> is - why not just put those classes in a normal SqueakEnh-Collections
> category?

Yes you're right, but... Ok I try to be more clear. I think that
extended a package/category could be a kind of extension/enhancement
proposal, but without to make explicitely this proposal. Not clear,
I'm sure ;-) For instance, I would like to say that I propose an
evolution of Collections-Unordered, so I have the solution you mention
to name a package SqueakEnh-Collections-Unordered (Here I help because
I give the information of where the new classes could be added in an
integration perspective). But to be more general, if I working in a
package X, and need to extend an existing package Y - let's note it
Y*, I would like to see Y* as an extension (in monticello browser for
instance in *Extensions), not as a separate package Y'. Because the
first intention was not to propose a new version of Y, but only an
extension I need. And people interested or maintaining Y could dig
into the several Y* and decide how to factorize it, if they want. I
don't know if you got the idea, but I feel that extension is not
evolution, the intention are different.

So for instance, if I'm working on a Graph package, I would like to
see in *Extensions : Collections-Unordered-*Graph-Core instead of
creating Collections-Unordered-2 which is a new version of
Collections-Unordered. When I browse X, I would like to see
immediately the different extended packages Y*, Z*, W*, and when I
load X, I would like that Y*, Z*, W* load automatically. But from now,
I have to package Y', Z', W' ; then load Y', Z', W' then X which is
time-consuming. The extension mechanism would allow a more economic
way quite easily. Moreover, it generalizes the extension methods
mechanism for packages... which is quite pretty ;-)

Cheers,
Samir


-- 
Samir SAIDANI				
PhD Student in CS / Doctorant en informatique 	web : http://www.info.unicaen.fr/~saidani
Universite de Caen - Laboratoire GREYC          tel : 02-31-56-74-30
Equipe MAD - Campus II - 14032 Caen Cedex       fax : 02-31-56-76-30