Hi Denis,


On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@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 <estebanlm@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 <dionisiydk@gmail.com> wrote:

Anybody else?

2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com>:


2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@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