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 <steph...@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 >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > > > -- www.tudorgirba.com "Every thing has its own flow"
