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"