Hi, On Tue, Feb 24, 2015 at 8:57 AM, stepharo <stepharo@free.fr> wrote:
Doru and Yuriy
String is not a good API for reflective operations. This is what you are doing with asPackage. When I want to access to a class I do Class or Smalltalk globals classNamed: 'Point'
As I said, there is already a String>>asClass. It seems that since it was introduced, people prefer to send Gofer scripts like: #ConfigurationOfXYZ asClass loadDevelopment instead of: (Smalltalk globals classNamed: 'ConfigurationOfXYZ') loadDevelopment a compile method Point>>#x
and not 'Point?x' asCompiledMethod
I think this is not quite the same: one is interpreting a notation and one is looking something up by name.
I would prefer to have Package named: 'jkljk' than the string behavior.
RPackage named: 'XYZ' already exists in the image and is a constructor that returns a new package object without looking it up in the organizer. Perhaps we can add RPackage class>>#@: RPackage @ 'XYZ' Yet, even in that case, working with this would require parentheses: (RPackage @ 'XYZ') linesOfCode I still somehow think that from a reader's point of view, this is more nice: 'XYZ' asPackage linesOfCode and what if I want to reflect on code that is remote?
Package named: 'aaa' would not solve that problem either. Still it would be reasonable solution would be Ok So I maintain that we are polluting String with reflective operations that
it should not have.
I see the point, and I would definitely like to have a first class support for important objects like packages. However, I think the problem is not so black and white. I see string extensions like this as a convenience that enables cheap fluent interfaces. For example, PetitParser relies on this pattern quite successfully. I can delete it from the system if it's so decided, but then we should also remove #asClass. Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"