I think the asymmetry would drive me bananas. I prefer the original set.
> On Sep 18, 2017, at 7:28 AM, Tudor Girba <[email protected]> wrote: > > Hi, > > In this case, it would sound better to have: > - pinInMemory > - unpinFromMemory > - isPinnedInMemory > - setPinnedInMemory: > > Cheers, > Doru > > >> On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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? >> >> 2017-09-14 9:28 GMT+02:00 H. Hirzel <[email protected] >> <mailto:[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 >> >> >> > >> >> > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > www.feenk.com > > "Every thing has its own flow." > > > > >
