Categorizing method extension with pragma
Locked
 
|
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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Categorizing method extension with pragma
|
|
yes now we should pay attention about metadata in the methods.
Now what we can have also is that the ***package*** knows the extension this is what my dead slowing making progress impelemntation is doing. 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
2010/1/10 Stéphane Ducasse <[hidden email]> 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 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.
-- Cédrick _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Categorizing method extension with pragma
|
|
On Jan 10, 2010, at 2:37 PM, Cédrick Béler wrote: > > 2010/1/10 Stéphane Ducasse <[hidden email]> > 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 ? it should now the problem is backward compatibility with MC. importing mc with conventions saving mc with conventions I discussed with lukas about what is the best way to handle that and now I forgot :) > > > 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 > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > -- > Cédrick > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Categorizing method extension with pragma
|
|
In reply to this post by cedreek
2010/1/10 Cédrick Béler <[hidden email]> Hi, That it would be a dream. I really hate the ugly hack to have to use Categories for another purpose than just organize methods regarding its intention. It is really disgusting. I don't have the knoweldege enought to say which solution I like most, but I can say that I hate as it is now and that I don't know the problems it can bring the Monticello and the compatibility. Maybe it would be easier when we have packages as real first class objects.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Categorizing method extension with pragma
|
|
In reply to this post by cedreek
2010/1/10 Cédrick Béler <[hidden email]> Hi, I don't like it because package location now means code changes. To move an extension method to another package one has to edit its source, and one would produce method differences when moving extension methods between packages.
I think the praqma makes sense for namespaces, where an extension method can be in a different namespace than the class it is on. e.g. consider a Tools namespace that includes inspectors. The inspectorClass extension methods on kernel classes (e.g. Dictionary>>inspectorClass ^DictionaryInspector) logically belong to the Tools namespace, not to some Kernel namespace. So writing
inspectorClass <environment: Tools.Inspectors> ^DictionaryInspector makes sense to me; it is directing the compiler to look for globals in the Tools.Inspector namespace, not elsewhere.
This is a semantic difference and so of a different kind to the merely organizational package structure. We had a loooong (and possibly still unresolved) debate about this at Cincom where I argued (until I was blue in the face) that package organization should be orthogonal to namespaces, and others argued that they should be conflated. Personally, I find extension methods an integral part of good OO design because they allow a framework to be extended in arbitrary clients without the core framework being filled with client-dependent code. Whether those extensions are in the class's package or in the framework's package might be a matter of history (e.g. whether the framework came before the client or not) but the functioning of the extension should be the same in either case.
So for me what package the code is in is a deployment/packaging issue, not a semantic one, and hence shouldn't be reflected in a pragma which is part of the method's source and metadata. But semantic issues (such as e.g. the namespace in which a method is compiled) can be reflected in pragmas.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Categorizing method extension with pragma
|
|
On Jan 11, 2010, at 1:01 AM, Eliot Miranda wrote: > > > 2010/1/10 Cédrick Béler <[hidden email]> > 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. > > I don't like it because package location now means code changes. To move an extension method to another package one has to edit its source, and one would produce method differences when moving extension methods between packages. > > I think the praqma makes sense for namespaces, where an extension method can be in a different namespace than the class it is on. e.g. consider a Tools namespace that includes inspectors. The inspectorClass extension methods on kernel classes (e.g. Dictionary>>inspectorClass ^DictionaryInspector) logically belong to the Tools namespace, not to some Kernel namespace. So writing > inspectorClass > <environment: Tools.Inspectors> > ^DictionaryInspector > makes sense to me; it is directing the compiler to look for globals in the Tools.Inspector namespace, not elsewhere. > > This is a semantic difference and so of a different kind to the merely organizational package structure. > > We had a loooong (and possibly still unresolved) debate about this at Cincom where I argued (until I was blue in the face) that package organization should be orthogonal to namespaces, I disagree :) But the point of been forced to edit the code to move method is a good point. > and others argued that they should be conflated. Personally, I find extension methods an integral part of good OO design because they allow a framework to be extended in arbitrary clients without the core framework being filled with client-dependent code. > Whether those extensions are in the class's package or in the framework's package might be a matter of history (e.g. whether the framework came before the client or not) but the functioning of the extension should be the same in either case. Yes > So for me what package the code is in is a deployment/packaging issue, not a semantic one, and hence shouldn't be reflected in a pragma which is part of the method's source and metadata. But semantic issues (such as e.g. the namespace in which a method is compiled) can be reflected in pragmas. Somehow yes. Even (after thinking several more than 10 soon about the issue) if the issue of having orthogonality between the two is not convincing and this is not because does it badly that merging the too is bad (even if Java does not have real namespace). What I would really like to experiment with is - late bound class name - import binding more or less following newspeak. But before that we have to experiment. Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |