And me ... Squeak and Cuis have the same name/implementation for - pin, unpin, isPinned, setPinned: (private) as we have in Pharo now (now also in the same method categories) and unnecessary differences/incompatibilities in the Kernel would not make much sense.
If it would really be necessary to change them it would only make sense to change them equally on all Open-Smalltalk VM based systems. Currently I also do not see any necessity. If there are clashes for Calypso tabs then why not change it there (with more specific method names like #isPinnedTab. #isPinnedToWindow or #isPinnedToBrowser) Bye T. Gesendet: Montag, 11. September 2017 um 14:16 Uhr Von: "Esteban Lorenzano" <[email protected]> An: "Pharo Development List" <[email protected]> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo]) 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
