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 <[hidden email]>:
I would use pinInMemory -- Pavel
|
Anybody else? 2017-08-31 10:29 GMT+02:00 Pavel Krivanek <[hidden email]>:
|
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
|
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
|
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]>:
|
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 |
> 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 ... |
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.2017-09-11 19:06 GMT+02:00 Torsten Bergmann <[hidden email]>: And me ... |
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]>:
|
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 >>>> >>> >>> >> >> > |
In reply to this post by Denis Kudriashov
Hi Denis,
|
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]>:
|
In reply to this post by Pavel Krivanek-3
+1
|
In reply to this post by Denis Kudriashov
Hi Denis,
On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <[hidden email]> wrote:
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?
_,,,^..^,,,_ best, Eliot |
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
|
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 |
In reply to this post by NorbertHartl
Hi Norbert,
|
+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 >> > |
Hello. 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 |
Free forum by Nabble | Edit this page |