I did pull request for issue 20426 <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>.
Interesting that Iceberg uses pinning in couple of places. I not touch it because it would not be single commit. And I have no idea how contribute in that case. I thing we are still in process to decide it. Anyway old messages are deprecated and users will continue work with auto transformation. 2017-09-14 17:27 GMT+02:00 Eliot Miranda <[email protected]>: > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <[email protected]> wrote: > > > > Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <[email protected]>: > > Hello. > > I guess we are agree to rename. I will prepare pull request for Pharo. And > Squeak is up to you. > > Here is the new messages: > - pinInMemory > - unpinInMemory > - isPinnedInMemory > - setPinnedInMemory: > > What was decision about #pinInMemoryDuring: ? Do we need it? > > I understand Eliot in a way that there is no real point in unpinning > objects. Hence pinDuring: is basically never useful and therefor adding a > selectir has rather a negative impact > > > +1 > > > Norbert > > 2017-09-14 9:28 GMT+02:00 H. Hirzel <[email protected]>: > >> +1 for pinInMemory >> >> It explains what it does. >> >> On 9/14/17, Eliot Miranda <[email protected]> wrote: >> > Hi Norbert, >> > >> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <[email protected]> wrote: >> >> >> >> >> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <[email protected] >> >: >> >>> >> >>> Hi Denis, >> >>> >> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < >> [email protected]> >> >>> wrote: >> >>>> Hi Eliot. >> >>>> >> >>>> I know and I only talk about new messages. I am not trying to rethink >> >>>> full meta model of Smalltalk. >> >>>> By the way #class is very common message and it is handy to use short >> >>>> name. But pinning messages will be used rarely in very specific >> >>>> applications. So no much sense to preserve them in short version. >> >>> >> >>> Agreed. So we have to decide whether to go with pinInMemory or >> >>> pinObject, pinObject being suggested by Norbert because it matched >> >>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you >> feel >> >>> strongly about pinObject et al? >> >>> >> >> No I don't. It feels only good to me if there is a requirement not to >> >> implement selectors that are likely to be used in user code. I'm ok >> with >> >> pinInMemory although I asked myself where can it be pinned elsewhere if >> >> not in memory. So the suffix in memory doesn't add anything but also >> moves >> >> the selector out of user space. >> > >> > Well I think Denis' point is that pinInMemory removes ambiguity with >> pin for >> > other uses and I agree. So I for one am happy to change it to >> pinInMemory >> > et al. >> > >> >> >> >> Norbert >> >> >> >>>> >> >>>> 2017-09-12 18:05 GMT+02:00 Eliot Miranda <[email protected]>: >> >>>>> Hi Denis, >> >>>>> >> >>>>> >> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov < >> [email protected]> >> >>>>>> wrote: >> >>>>>> >> >>>>>> I am really wonder guys. I thought you are not big funs of Object >> >>>>>> protocol. >> >>>>>> Current pinning messages are a new set of very generic messages in >> the >> >>>>>> Object. >> >>>>> >> >>>>> Yes, and that's because this is a fundamental property of all >> >>>>> non-immediate objects. Do you object to the #class message? >> Should it >> >>>>> be #classObject because it might conflict with #class used in an >> >>>>> educational or socioeconomic model? All objects other than >> immediates >> >>>>> can move. Pinning stops that movement. It applies generally. So >> the >> >>>>> protocol belongs in Object. >> >>>>> >> >>>>> >> >>>>>> >> >>>>>> About Norbert idea. >> >>>>>> - bePinnedObject is not bad convention. But I would prefer the >> memory >> >>>>>> suffix because it reflects the low level behaviour. >> >>>>>> >> >>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano <[email protected] >> >: >> >>>>>>> yes, me :) >> >>>>>>> >> >>>>>>> I do not see a reason to change them, tbh. >> >>>>>>> for me they are comprensible as they are now and it does not adds >> >>>>>>> more information pinInMemory or pinMemory. >> >>>>>>> >> >>>>>>> Esteban >> >>>>>>> >> >>>>>>> >> >>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov <[email protected] >> > >> >>>>>>>> wrote: >> >>>>>>>> >> >>>>>>>> Anybody else? >> >>>>>>>> >> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >> >>>>>>>> <[email protected]>: >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >> >>>>>>>>> <[email protected]>: >> >>>>>>>>>> Hi. >> >>>>>>>>>> >> >>>>>>>>>> We now have very generic message names: >> >>>>>>>>>> - pin >> >>>>>>>>>> - unpin >> >>>>>>>>>> - setPinned: >> >>>>>>>>>> - isPinned >> >>>>>>>>>> >> >>>>>>>>>> Problem that they collide with possible domain related names. >> >>>>>>>>>> For example I implemented pinning of tabs in Calypso and I >> found >> >>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it >> with >> >>>>>>>>>> different names. >> >>>>>>>>>> Probably menus also uses pin word but without overrides >> >>>>>>>>>> >> >>>>>>>>>> What you think about renaming pinning messages? Something like: >> >>>>>>>>>> - pinMemory >> >>>>>>>>> >> >>>>>>>>> I would use pinInMemory >> >>>>>>>>> >> >>>>>>>>> -- Pavel >> >>>>>>>>> >> >>>>>>>>>> - unpinMemory >> >>>>>>>>>> - isMemoryPinned >> >>>>>>>>>> - setPinnedMemory: >> >>>>>>>>>> - pinMemoryDuring: (if we will introduce it) >> >>>>>>>>>> >> >>>>>>>>>> I think it is easy to do now because not much code uses pinning >> >>>>>>>>> >> >>>>>>>> >> >>>>>>> >> >>>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> _,,,^..^,,,_ >> >>> best, Eliot >> >> >> > >> >> >
