#storeOn: question
Locked
 
|
Hi,
SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems. werner |
Re: #storeOn: question
|
|
Werner,
> On 30 Nov 2015, at 15:15, Werner Kassens <[hidden email]> wrote: > > Hi, > SortedCollection>>storeOn: seems to have a little problem since it does not store sortBlock and the used super-method (in Collection) uses #add: which uses sortBlock and their default uses #<=, hence if the elements are not comparable via #<=, but need a special sortblock, one gets an error on retrieving that collection. of course i can circumvent that tiny problem by defining #<= or using fuel, but i wonder whether i should report that on the bugtracker? btw perhaps some other collections with instanceVariables which do not define their own #storeOn: (eg Heap) could also have eventually some problems. > werner I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real. But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it. Sven |
|
|
On Mon, Nov 30, 2015 at 11:23 AM, Sven Van Caekenberghe <[hidden email]> wrote: Werner, Yes, I have the same feeling. And I hate having such a general protocol like #storeOn: in our kernel objects. Store how? using which serializer? I think if this protocol is still used it should be much clearer. But as Sven said, I am not sure if this is still used and if it does, which code use it, who is the "serializer", etc... |
|
|
In reply to this post by Sven Van Caekenberghe-2
Hi Sven,
i see, then i'll simply forget it (i asked, because i halfway expected that). thanks for that info. werner On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote: > I am not so sure the #storeOn: / #readFrom: mechanism is still being maintained. I am not using it in any case, I thought it was mostly broken. I would be surprised if someone is still using it for real. > > But I might be wrong. In that case there should be a suite of real unit tests that defines and maintains the expected behaviour. And then you would be right, we should fix it. > > Sven > |
|
|
Wait :)
Help us :) It would be good to check who is using that and evaluate if we can remove it. Stef Le 30/11/15 15:29, Werner Kassens a écrit : > Hi Sven, > i see, then i'll simply forget it (i asked, because i halfway expected > that). thanks for that info. > werner > > On 11/30/2015 03:23 PM, Sven Van Caekenberghe wrote: >> I am not so sure the #storeOn: / #readFrom: mechanism is still being >> maintained. I am not using it in any case, I thought it was mostly >> broken. I would be surprised if someone is still using it for real. >> >> But I might be wrong. In that case there should be a suite of real >> unit tests that defines and maintains the expected behaviour. And >> then you would be right, we should fix it. >> >> Sven >> > > |
|
|
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. |
|
|
Thanks Werner!
Stef Le 3/12/15 13:00, Werner Kassens a écrit : > 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. > > |
|
|
In reply to this post by wernerk
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:  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 <[hidden email]> wrote: |
|
|
Hi again,
> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." |
|
|
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 <[hidden email]> wrote: > > Hi again, > >> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." |
|
|
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 <[hidden email]> wrote: >> >> Hi again, >> >>> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." > > > > > |
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: >>> >>> Hi again, >>> >>>> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." |
|
|
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 <[hidden email]> 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 <[hidden email]> wrote: >>>> >>>> Hi again, >>>> >>>>> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." > > > |
|
|
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote: >>>>> >>>>> Hi again, >>>>> >>>>>> On Dec 9, 2015, at 3:30 PM, Tudor Girba <[hidden email]> 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 <[hidden email]> 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." > > |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |