So it is integrated it Pharo 7 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com>:
> 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 <eliot.mira...@gmail.com>: > >> >> On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norb...@hartl.name> wrote: >> >> >> >> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisi...@gmail.com>: >> >> 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 <hannes.hir...@gmail.com>: >> >>> +1 for pinInMemory >>> >>> It explains what it does. >>> >>> On 9/14/17, Eliot Miranda <eliot.mira...@gmail.com> wrote: >>> > Hi Norbert, >>> > >>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norb...@hartl.name> >>> wrote: >>> >> >>> >> >>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda < >>> eliot.mira...@gmail.com>: >>> >>> >>> >>> Hi Denis, >>> >>> >>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < >>> dionisi...@gmail.com> >>> >>> 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 <eliot.mira...@gmail.com>: >>> >>>>> Hi Denis, >>> >>>>> >>> >>>>> >>> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov < >>> dionisi...@gmail.com> >>> >>>>>> 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 <esteba...@gmail.com >>> >: >>> >>>>>>> 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 < >>> dionisi...@gmail.com> >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> Anybody else? >>> >>>>>>>> >>> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>> >>>>>>>> <pavel.kriva...@gmail.com>: >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>> >>>>>>>>> <dionisi...@gmail.com>: >>> >>>>>>>>>> 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 >>> >> >>> > >>> >>> >> >
