2010/1/10 St��phane Ducasse <stephane.ducasse@inria.fr>

yes now we should pay attention about metadata in the methods.

yes this is an extra thing to do but it might be necessary. Also it can be sort of "transparent".

Imagine I download an image and start my new project. So I use a "project browser" (a packages context oriented browser), ie a classical browser that create new packages and each time I add extension methods, the metadata are associated automaticaly.

��

Now what we can have also is that the ***package*** knows the extension
this is what my dead slowing making progress impelemntation is doing.

uhm ok :) Maybe better.. so I'll wait and see ;) Would that autorize to have a classic method category name ? or will it still be *apackage ?

What's difficult here to me is that maybe we need to stay backward compatible or see if squeakers want to adopt the same strategy wich is not that easy I guess.

��

On Jan 10, 2010, at 2:08 PM, C��drick B��ler wrote:

> Hi,
>
> Just a 2 cents thought on method extension.
>
> Why not associating a pragma instead of using the package name prefixed by a star ?
>
> Say there is a package named MyPackage and I override a method in String or add a new one. What I'd like is keeping the original method category name (or find an appropriate one) instead of using *mypackage. For instance:
>
> String>>aMethod
> <package: MyPackage>
> ...
> ...
> ^result
>
>
> Then, we would have to adapt monticello for that purpose. We could also use dynamic protocols to get the list of extension method by package.
>
> What does other think ? I find it could be a good starting point to deal with packages.
>
>
>
> --
> C��drick

> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project