Maybe better pinning messages? (inspired by [Pinning Objects in Pharo])

2017-09-14 9:28 GMT+02:00 H. Hirzel <[hidden email]>:

+1 for pinInMemory

It explains what it does.

On 9/14/17, Eliot Miranda <[hidden email]> wrote:
> Hi Norbert,
>
>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <[hidden email]> wrote:
>>
>>
>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <[hidden email]>:
>>>
>>> Hi Denis,
>>>
>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <[hidden email]>
>>> 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 <[hidden email]>:
>>>>> Hi Denis,
>>>>>
>>>>>
>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Anybody else?
>>>>>>>>
>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>>>>>>> <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>>>>>>>>> <[hidden email]>:
>>>>>>>>>> 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
>>
>

Norbert

2017-09-14 9:28 GMT+02:00 H. Hirzel <[hidden email]>:

+1 for pinInMemory

It explains what it does.

On 9/14/17, Eliot Miranda <[hidden email]> wrote:
> Hi Norbert,
>
>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <[hidden email]> wrote:
>>
>>
>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <[hidden email]>:
>>>
>>> Hi Denis,
>>>
>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <[hidden email]>
>>> 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 <[hidden email]>:
>>>>> Hi Denis,
>>>>>
>>>>>
>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Anybody else?
>>>>>>>>
>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>>>>>>> <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>>>>>>>>> <[hidden email]>:
>>>>>>>>>> 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 10:17 AM, Denis Kudriashov <[hidden email]> 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 <[hidden email]>:
+1 for pinInMemory

It explains what it does.

On 9/14/17, Eliot Miranda <[hidden email]> wrote:

> Hi Norbert,
>
>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <[hidden email]> wrote:
>>
>>
>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <[hidden email]>:
>>>
>>> Hi Denis,
>>>
>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <[hidden email]>
>>> 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 <[hidden email]>:
>>>>> Hi Denis,
>>>>>
>>>>>
>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Anybody else?
>>>>>>>>
>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>>>>>>> <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>>>>>>>>> <[hidden email]>:
>>>>>>>>>> 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 <[hidden email]> wrote:

So it is integrated it Pharo 7 

2017-09-18 11:09 GMT+02:00 Denis Kudriashov <[hidden email]>:

I did pull request for issue 20426.

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 <[hidden email]>:

On Sep 14, 2017, at 7:07 AM, Norbert Hartl <[hidden email]> wrote:

Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <[hidden email]>:

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 <[hidden email]>:

+1 for pinInMemory

It explains what it does.

On 9/14/17, Eliot Miranda <[hidden email]> wrote:
> Hi Norbert,
>
>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <[hidden email]> wrote:
>>
>>
>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <[hidden email]>:
>>>
>>> Hi Denis,
>>>
>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <[hidden email]>
>>> 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 <[hidden email]>:
>>>>> Hi Denis,
>>>>>
>>>>>
>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <[hidden email]>
>>>>>> 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 <[hidden email]>:
>>>>>>> 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 <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Anybody else?
>>>>>>>>
>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>>>>>>> <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>>>>>>>>> <[hidden email]>:
>>>>>>>>>> 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
>>
>