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