> 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 >>> >> >>> > >>> >>
