> On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisi...@gmail.com> wrote: > > So it is integrated it Pharo 7 > > 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisi...@gmail.com > <mailto:dionisi...@gmail.com>>: > I did pull request for issue 20426 > <https://pharo.fogbugz.com/f/cases/20426/Better-pin-messages>. > > Interesting that Iceberg uses pinning in couple of places. I not touch it > because it would not be single commit. And I have no idea how contribute in > that case. I thing we are still in process to decide it. > Anyway old messages are deprecated and users will continue work with auto > transformation.
and we cannot just change it right now because for the moment we want iceberg to be loadable in Pharo 6.1. so we will continue using deprecated messages until we drop compatibility. Esteban > > 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.mira...@gmail.com > <mailto:eliot.mira...@gmail.com>>: > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norb...@hartl.name > <mailto:norb...@hartl.name>> wrote: > >> >> >> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisi...@gmail.com >> <mailto:dionisi...@gmail.com>>: >> >>> 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 <hannes.hir...@gmail.com >>> <mailto:hannes.hir...@gmail.com>>: >>> +1 for pinInMemory >>> >>> It explains what it does. >>> >>> On 9/14/17, Eliot Miranda <eliot.mira...@gmail.com >>> <mailto:eliot.mira...@gmail.com>> wrote: >>> > Hi Norbert, >>> > >>> >> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norb...@hartl.name >>> >> <mailto:norb...@hartl.name>> wrote: >>> >> >>> >> >>> >>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.mira...@gmail.com >>> >>> <mailto:eliot.mira...@gmail.com>>: >>> >>> >>> >>> Hi Denis, >>> >>> >>> >>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisi...@gmail.com >>> >>> <mailto: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 >>> >>>> <mailto:eliot.mira...@gmail.com>>: >>> >>>>> Hi Denis, >>> >>>>> >>> >>>>> >>> >>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisi...@gmail.com >>> >>>>>> <mailto: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 >>> >>>>>> <mailto: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 >>> >>>>>>>> <mailto:dionisi...@gmail.com>> >>> >>>>>>>> wrote: >>> >>>>>>>> >>> >>>>>>>> Anybody else? >>> >>>>>>>> >>> >>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>> >>>>>>>> <pavel.kriva...@gmail.com <mailto:pavel.kriva...@gmail.com>>: >>> >>>>>>>>> >>> >>>>>>>>> >>> >>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>> >>>>>>>>> <dionisi...@gmail.com <mailto: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 >>> >> >>> > >>> >>> > >
