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 >
