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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
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
Reply | Threaded
Open this post in threaded view
|

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

Pavel Krivanek-3


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

Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
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


Reply | Threaded
Open this post in threaded view
|

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

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

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



Reply | Threaded
Open this post in threaded view
|

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

EstebanLM
In reply to this post by Denis Kudriashov
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



Reply | Threaded
Open this post in threaded view
|

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

Esteban A. Maringolo
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 <[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




Reply | Threaded
Open this post in threaded view
|

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

Torsten Bergmann
In reply to this post by EstebanLM
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" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote: 

Anybody else?
 
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <[hidden email][mailto:[hidden email]]>:
 
 
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <[hidden email][mailto:[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

Reply | Threaded
Open this post in threaded view
|

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

Peter Uhnak
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 <[hidden email]> 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" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote: 

Anybody else?
 
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <[hidden email][mailto:[hidden email]]>:
 
 
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <[hidden email][mailto:[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


Reply | Threaded
Open this post in threaded view
|

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

Nicolas Cellier
In reply to this post by Torsten Bergmann
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 <[hidden email]>:
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" <[hidden email]>
An: "Pharo Development List" <[hidden email]>
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 <[hidden email][mailto:[hidden email]]> wrote: 

Anybody else?
 
2017-08-31 10:29 GMT+02:00 Pavel Krivanek <[hidden email][mailto:[hidden email]]>:
 
 
2017-08-31 10:24 GMT+02:00 Denis Kudriashov <[hidden email][mailto:[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


Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
In reply to this post by EstebanLM
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 <[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




Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
On 9/12/17, 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.
>
> 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 <[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
>>>>
>>>
>>>
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Denis Kudriashov
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




Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
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 <[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





Reply | Threaded
Open this post in threaded view
|

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

tblanchard
In reply to this post by Pavel Krivanek-3
+1

On Aug 31, 2017, at 1:29 AM, Pavel Krivanek <[hidden email]> wrote:

I would use pinInMemory

Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by Denis Kudriashov
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?
 

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
Reply | Threaded
Open this post in threaded view
|

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

NorbertHartl

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. 

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

Reply | Threaded
Open this post in threaded view
|

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

David T. Lewis
On Thu, Sep 14, 2017 at 12:18:34AM +0200, Norbert Hartl 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] <mailto:[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.
>

+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


Reply | Threaded
Open this post in threaded view
|

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

Eliot Miranda-2
In reply to this post by NorbertHartl
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

Reply | Threaded
Open this post in threaded view
|

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

Hannes Hirzel
+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
>>
>

Reply | Threaded
Open this post in threaded view
|

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

Denis Kudriashov
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
>>
>


12