Hi,

Indeed, having all "asXYZ from the Earth" would not be desirable to have in the Kernel, but:
- asPackage is packaged in��*RPackage-SystemIntegration, so it's not in the Kernel
- I think extending String is a cheap and rather elegant way to ease common access patterns, and in this case RPackage is a common thing to look at.

So, from this perspective, I think it is good to have asPackage.

If my main system would be something about Players, and I would need ways to script that be sure I would have an asPlayer in my image (not in Pharo though :)).

I would have actually preferred to put this in Symbol, but I saw that asClass is in String and I implemented it in the same way.

Cheers,
Doru

On Mon, Feb 23, 2015 at 11:16 PM, stepharo <stepharo@free.fr> wrote:

It is symmetrical to String>>asClass which proves rather elegant for scripting class lookup.

Why is it not good?
 Because you are binding RPackage (which is for now a layer on top of class) directly inside the kernel
and this should not be done like that. May be you defined it as a class extension (I hope) I could not see the code.
We should stop extending core classes. It makes the system more complex to maintain and decompose.

String should not contain all the asXXXX methods from earth.
Why we do not have asMethod, asPoint, asPlayer, asSound ?

Stef



Le 23/2/15 15:53, Sven Van Caekenberghe a ��crit :
Cool, we're back in business ;-)

 yes but why having String>>asPackage is better?

Stef




--

"Every thing has its own flow"




--
www.tudorgirba.com

"Every thing has its own flow"