On Mon, Sep 18, 2017 at 10:38 PM, Todd Blanchard <[email protected]> wrote: > I think the asymmetry would drive me bananas. > I prefer the original set. >
+1. Think of it this way.... un-"pinInMemory" cheers -ben > 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]> 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]>: > +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 > www.feenk.com > > "Every thing has its own flow." > > > > > >
