Indeed we could.
Coudl you add an issue?
On Thu, Sep 28, 2017 at 12:43 PM, Torsten Bergmann <[email protected]> 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" <[email protected]>
> An: "Pharo Development List" <[email protected]>
> Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning
> Objects in Pharo])
>
>
>
> On 28 Sep 2017, at 10:01, Denis Kudriashov
> <[email protected][mailto:[email protected]]> wrote:
>
> So it is integrated it Pharo 7
>
> 2017-09-18 11:09 GMT+02:00 Denis Kudriashov
> <[email protected][mailto:[email protected]]>:
> 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
> <[email protected][mailto:[email protected]]>:
>
>
> On Sep 14, 2017, at 7:07 AM, Norbert Hartl
> <[email protected][mailto:[email protected]]> wrote:
>
>
>
>
> Am 14.09.2017 um 10:17 schrieb Denis Kudriashov
> <[email protected][mailto:[email protected]]>:
>
>
> 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
> <[email protected][mailto:[email protected]]>:+1 for pinInMemory
>
> It explains what it does.
>
> On 9/14/17, Eliot Miranda
> <[email protected][mailto:[email protected]]> wrote:
>> Hi Norbert,
>>
>>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl
>>> <[email protected][mailto:[email protected]]> wrote:
>>>
>>>
>>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda
>>>> <[email protected][mailto:[email protected]]>:
>>>>
>>>> Hi Denis,
>>>>
>>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov
>>>> <[email protected][mailto:[email protected]]>
>>>> wrote:
>>>>> Hi Eliot.
>>>>>
>>>>> I know and I only talk about new messages. I am not trying to rethink
>>>>> full meta model of Smalltalk.
>>>>> By the way #class is very common message and it is handy to use short
>>>>> name. But pinning messages will be used rarely in very specific
>>>>> applications. So no much sense to preserve them in short version.
>>>>
>>>> Agreed. So we have to decide whether to go with pinInMemory or
>>>> pinObject, pinObject being suggested by Norbert because it matched
>>>> isReadOnlyObject. Personally I like pinInMemory. Norbert, do you feel
>>>> strongly about pinObject et al?
>>>>
>>> No I don't. It feels only good to me if there is a requirement not to
>>> implement selectors that are likely to be used in user code. I'm ok with
>>> pinInMemory although I asked myself where can it be pinned elsewhere if
>>> not in memory. So the suffix in memory doesn't add anything but also moves
>>> the selector out of user space.
>>
>> 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
>>>>> <[email protected][mailto:[email protected]]>:
>>>>>> Hi Denis,
>>>>>>
>>>>>>
>>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov
>>>>>>> <[email protected][mailto:[email protected]]>
>>>>>>> wrote:
>>>>>>>
>>>>>>> I am really wonder guys. I thought you are not big funs of Object
>>>>>>> protocol.
>>>>>>> Current pinning messages are a new set of very generic messages in the
>>>>>>> Object.
>>>>>>
>>>>>> Yes, and that's because this is a fundamental property of all
>>>>>> non-immediate objects. Do you object to the #class message? Should it
>>>>>> be #classObject because it might conflict with #class used in an
>>>>>> educational or socioeconomic model? All objects other than immediates
>>>>>> can move. Pinning stops that movement. It applies generally. So the
>>>>>> protocol belongs in Object.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> About Norbert idea.
>>>>>>> - bePinnedObject is not bad convention. But I would prefer the memory
>>>>>>> suffix because it reflects the low level behaviour.
>>>>>>>
>>>>>>> 2017-09-11 14:16 GMT+02:00 Esteban Lorenzano
>>>>>>> <[email protected][mailto:[email protected]]>:
>>>>>>>> yes, me :)
>>>>>>>>
>>>>>>>> I do not see a reason to change them, tbh.
>>>>>>>> for me they are comprensible as they are now and it does not adds
>>>>>>>> more information pinInMemory or pinMemory.
>>>>>>>>
>>>>>>>> Esteban
>>>>>>>>
>>>>>>>>
>>>>>>>>> On 11 Sep 2017, at 11:56, Denis Kudriashov
>>>>>>>>> <[email protected][mailto:[email protected]]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Anybody else?
>>>>>>>>>
>>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek
>>>>>>>>> <[email protected][mailto:[email protected]]>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov
>>>>>>>>>> <[email protected][mailto:[email protected]]>:
>>>>>>>>>>> Hi.
>>>>>>>>>>>
>>>>>>>>>>> We now have very generic message names:
>>>>>>>>>>> - pin
>>>>>>>>>>> - unpin
>>>>>>>>>>> - setPinned:
>>>>>>>>>>> - isPinned
>>>>>>>>>>>
>>>>>>>>>>> Problem that they collide with possible domain related names.
>>>>>>>>>>> For example I implemented pinning of tabs in Calypso and I found
>>>>>>>>>>> that I overrides #pin and #isPinned messages. Then I fix it with
>>>>>>>>>>> different names.
>>>>>>>>>>> Probably menus also uses pin word but without overrides
>>>>>>>>>>>
>>>>>>>>>>> What you think about renaming pinning messages? Something like:
>>>>>>>>>>> - pinMemory
>>>>>>>>>>
>>>>>>>>>> I would use pinInMemory
>>>>>>>>>>
>>>>>>>>>> -- Pavel
>>>>>>>>>>
>>>>>>>>>>> - unpinMemory
>>>>>>>>>>> - isMemoryPinned
>>>>>>>>>>> - setPinnedMemory:
>>>>>>>>>>> - pinMemoryDuring: (if we will introduce it)
>>>>>>>>>>>
>>>>>>>>>>> I think it is easy to do now because not much code uses pinning
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> _,,,^..^,,,_
>>>> best, Eliot
>>>
>>
>
>
