Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])
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 - unpinMemory - isMemoryPinned - setPinnedMemory: - pinMemoryDuring: (if we will introduce it) I think it is easy to do now because not much code uses pinning
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
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
I don't think we should come up with a new naming scheme every now and then. If I look at the read-only support there the selector is beReadOnlyObject so in this case it should be bePinnedObject I didn't like the extra Object at the end but now I think it makes it clear and still steps aside for user code to implement something like pin/unpin/bePinned Norbert
Am 11.09.2017 um 11:56 schrieb Denis Kudriashov <dionisiydk@gmail.com>:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto: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
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 <mailto:pavel.krivanek@gmail.com>>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto: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
I understand it's not about the intention revealing of the selector, but about not making #pin:/#unpin: a kind of "reserved selector" as many implemented in Object. Regards, Esteban A. Maringolo 2017-09-11 9:16 GMT-03: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
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" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: Anybody else?  2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>:   2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto: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
for me they are comprensible as they are now and it does not adds more information pinInMemory or pinMemory.
it is not about comprehension, but about not mixing meta and domain selectors. On Mon, Sep 11, 2017 at 7:06 PM, Torsten Bergmann <astares@gmx.de> wrote:
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" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 <dionisiydk@gmail.com[mailto:d ionisiydk@gmail.com]> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[ mailto:pavel.krivanek@gmail.com]>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:d ionisiydk@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
Hi Torsten, it's early enough for that change to happen in all dialects, no backward compatibility support necessary, no deprecation policy, so if Pharo comes with good selectors we can make them universal. Nicolas 2017-09-11 19:06 GMT+02:00 Torsten Bergmann <astares@gmx.de>:
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" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> 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 <dionisiydk@gmail.com[mailto:d ionisiydk@gmail.com]> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[ mailto:pavel.krivanek@gmail.com]>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:d ionisiydk@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
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. 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
On 9/12/17, 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.
About Norbert idea. - bePinnedObject is not bad convention.
But I would prefer the memory suffix because it reflects the low level behaviour. +1
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
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
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. 2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
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
Hi Denis, On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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?
2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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. Norbert
2017-09-12 18:05 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>: Hi Denis,
On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto: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 <mailto: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 <mailto:dionisiydk@gmail.com>> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto: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
-- _,,,^..^,,,_ best, Eliot
On Thu, Sep 14, 2017 at 12:18:34AM +0200, Norbert Hartl wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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.
+1 I also like pinInMemory because it is easy to read and it describes exactly what the method does. It pins the object to some location in the object memory. Once you stick a pin in it, the object stops moving around in the object memory. Nice. Dave
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
+1 for pinInMemory It explains what it does. On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
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? 2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>:
+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com :
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@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 Norbert
2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>:
+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@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.hirzel@gmail.com>:
+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
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. 2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@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.hirzel@gmail.com>:
+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com :
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
So it is integrated it Pharo 7 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@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.
2017-09-14 17:27 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@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.hirzel@gmail.com>:
+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda < eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com> wrote:
So it is integrated it Pharo 7
2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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.hirzel@gmail.com <mailto:hannes.hirzel@gmail.com>>: +1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name <mailto:norbert@hartl.name>> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@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.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:
Hi Denis,
On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto: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 <mailto: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 <mailto:dionisiydk@gmail.com>> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com <mailto:pavel.krivanek@gmail.com>>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com <mailto: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
-- _,,,^..^,,,_ best, Eliot
Why not make a backport to Pharo 6.1 with the new pinned message and provide it in a 60511 (last update is 60510 as of today). I know it is effort but that way you can be compatible and use the new methods.  Thanks T.  Gesendet: Donnerstag, 28. September 2017 um 10:19 Uhr Von: "Esteban Lorenzano" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])  On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: So it is integrated it Pharo 7  2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:  On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote:    Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.hirzel@gmail.com[mailto:hannes.hirzel@gmail.com]>:+1 for pinInMemory It explains what it does. On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:
Hi Denis,
On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto: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[mailto: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[mailto:dionisiydk@gmail.com]> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto: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
-- _,,,^..^,,,_ best, Eliot
Â
Indeed we could. Coudl you add an issue? On Thu, Sep 28, 2017 at 12:43 PM, Torsten Bergmann <astares@gmx.de> wrote:
Why not make a backport to Pharo 6.1 with the new pinned message and provide it in a 60511 (last update is 60510 as of today). I know it is effort but that way you can be compatible and use the new methods.
Thanks T.
Gesendet: Donnerstag, 28. September 2017 um 10:19 Uhr Von: "Esteban Lorenzano" <estebanlm@gmail.com> An: "Pharo Development List" <pharo-dev@lists.pharo.org> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])
On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote:
So it is integrated it Pharo 7
2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:
On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote:
Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.hirzel@gmail.com[mailto:hannes.hirzel@gmail.com]>:+1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@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.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>:
Hi Denis,
On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto: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[mailto: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[mailto:dionisiydk@gmail.com]> wrote:
Anybody else?
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>:
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto: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
-- _,,,^..^,,,_ best, Eliot
Hi, In this case, it would sound better to have: - pinInMemory - unpinFromMemory - isPinnedInMemory - setPinnedInMemory: Cheers, Doru
On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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?
2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>: +1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
-- www.tudorgirba.com www.feenk.com "Every thing has its own flow."
I think the asymmetry would drive me bananas. I prefer the original set.
On Sep 18, 2017, at 7:28 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
In this case, it would sound better to have: - pinInMemory - unpinFromMemory - isPinnedInMemory - setPinnedInMemory:
Cheers, Doru
On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:
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?
2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com <mailto:hannes.hirzel@gmail.com>>: +1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
-- www.tudorgirba.com <http://www.tudorgirba.com/> www.feenk.com
"Every thing has its own flow."
On Mon, Sep 18, 2017 at 10:38 PM, Todd Blanchard <tblanchard@mac.com> wrote:
I think the asymmetry would drive me bananas. I prefer the original set.
+1. Think of it this way.... un-"pinInMemory" cheers -ben
On Sep 18, 2017, at 7:28 AM, Tudor Girba <tudor@tudorgirba.com> wrote:
Hi,
In this case, it would sound better to have: - pinInMemory - unpinFromMemory - isPinnedInMemory - setPinnedInMemory:
Cheers, Doru
On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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?
2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>: +1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com>:
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
2017-09-18 16:28 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:
Hi,
In this case, it would sound better to have: - pinInMemory - unpin*From*Memory
Then first message can be named #pinToMemory. But I prefer simple InMemory for both cases.
- isPinnedInMemory - setPinnedInMemory:
Cheers, Doru
On Sep 14, 2017, at 10:17 AM, Denis Kudriashov <dionisiydk@gmail.com> wrote:
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?
2017-09-14 9:28 GMT+02:00 H. Hirzel <hannes.hirzel@gmail.com>: +1 for pinInMemory
It explains what it does.
On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Hi Norbert,
On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name> wrote:
Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com :
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov < dionisiydk@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.miranda@gmail.com>:
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
-- _,,,^..^,,,_ best, Eliot
-- www.tudorgirba.com www.feenk.com
"Every thing has its own flow."
participants (15)
-
Ben Coman -
David T. Lewis -
Denis Kudriashov -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
H. Hirzel -
Nicolas Cellier -
Norbert Hartl -
Pavel Krivanek -
Peter Uhnák -
Stephane Ducasse -
Todd Blanchard -
Torsten Bergmann -
Tudor Girba