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 <stepharo@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 <stepharo@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 <tudor@tudorgirba.com> wrote:
Hi again,
On Dec 9, 2015, at 3:30 PM, Tudor Girba <tudor@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 <wkassens@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."