Hi,
On Tue, Feb 24, 2015 at 8:57 AM, stepharo <steph...@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"
