Hi, It would certainly not be in Core. I was thinking it to be in Ring.
Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow" > On 21 Dec 2015, at 23:03, stepharo <steph...@free.fr> wrote: > > How this method is packaged? Because I do not want to have in the core like > that especially if it add dependencies to MC > > Stef > > Le 16/12/15 22:47, Tudor Girba a écrit : >> Hi, >> >> I wanted to have an easy way to distinguish between a class that ships with >> Pharo and another class that is built on top. Unfortunately, I did not find >> a good enough heuristic (I used to rely on the repository of the package >> where the class is defined as being the Pharo one), so this was not added >> until we find a different solution. >> >> This is useful in several situations. The one I am in very often is to use >> extra tools that are in Moose to analyze Pharo. This was the case below >> where we needed to get the list of the storeOn: senders more accurately. >> >> Cheers, >> Doru >> >> >>> On Dec 16, 2015, at 10:41 PM, stepharo <steph...@free.fr> wrote: >>> >>> hi doru >>> >>> what is isPharoClass? >>> Why do you need it? >>> >>> Stef >>> >>> Le 9/12/15 21:49, Tudor Girba a écrit : >>>> I created an issue with a slice: >>>> https://pharo.fogbugz.com/f/cases/17224/TBehavior-isPharo >>>> >>>> Cheers, >>>> Doru >>>> >>>> >>>>> On Dec 9, 2015, at 3:33 PM, Tudor Girba <tu...@tudorgirba.com> wrote: >>>>> >>>>> Hi again, >>>>> >>>>>> On Dec 9, 2015, at 3:30 PM, Tudor Girba <tu...@tudorgirba.com> wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> Thanks for the question. I am at a conference, and I just took this >>>>>> problem to explain someone what code querying can mean :). >>>>>> >>>>>> Here is the result: >>>>>> http://ws.stfx.eu/CCSNJVWX3JKS >>>>> I just realized that isPharoClass only exists in my image for the moment >>>>> :) >>>>> >>>>> Doru >>>>> >>>>> >>>>>> <storeOn.png> >>>>>> >>>>>> I think this is how we should document our communication because now we >>>>>> have the tools. >>>>>> >>>>>> Cheers, >>>>>> Doru >>>>>> >>>>>> >>>>>>> On Dec 3, 2015, at 7:00 AM, Werner Kassens <wkass...@libello.com> wrote: >>>>>>> >>>>>>> Hi Stephane, >>>>>>> there are 89 senders of #storeOn: minus around 30 implementations of >>>>>>> #storeOn: minus around 10 tests, also things like the >>>>>>> PharoChangesCondenser use it. then there are 26 senders of #storeString >>>>>>> (essentially the same functionality implemented via #storeOn:, but >>>>>>> returns a string) eg used by the StartupPreferencesLoader. and there >>>>>>> are several senders of #store: that are not implementations of >>>>>>> #storeOn:. iow deprecating #storeOn: looks a bit complicated to me and >>>>>>> is obviously way above my head. >>>>>>> werner >>>>>>> >>>>>>>> On 11/30/2015 09:42 PM, stepharo wrote: >>>>>>>> It would be good to check who is using that and evaluate if we can >>>>>>>> remove it. >>>>>> -- >>>>>> www.tudorgirba.com >>>>>> >>>>>> "Every thing should have the right to be different." >>>>> -- >>>>> www.tudorgirba.com >>>>> >>>>> "One cannot do more than one can do." >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Yesterday is a fact. >>>> Tomorrow is a possibility. >>>> Today is a challenge." >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "It's not what we do that matters most, it's how we do it." > >
