> 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] > <mailto:[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.
Norbert > > 2017-09-12 18:05 GMT+02:00 Eliot Miranda <[email protected] > <mailto:[email protected]>>: > Hi Denis, > > > On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <[email protected] > <mailto:[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] >> <mailto:[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] >>> <mailto:[email protected]>> wrote: >>> >>> Anybody else? >>> >>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <[email protected] >>> <mailto:[email protected]>>: >>> >>> >>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov <[email protected] >>> <mailto:[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
