On Jan 11, 2010, at 1:01 AM, Eliot Miranda wrote:
2010/1/10 Cédrick Béler <cdrick65@gmail.com> 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