Pragma keyword / selector / methodSelector

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <[hidden email]> wrote:
>
> On 14/11/2016 15:50, Denis Kudriashov wrote:
>>
>> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>    Breaking Metacello in any version = Not good.
>>
>>    Metacello is very backward compatible but breaking pragma semantics
>>    would require a rewrite of many configurations that work okay today
>>
>>
>> Why? ConfigurationOf~ not collect any pragmas by themselves. They only
>> declare versions by pragmas.
>> And we only need to fix Pharo version of Metacello which is already fork.
>
> Changes to Metacello should be done on metacello-work repository and not
> only on Pharo. Else we will not be able to load the latest Metacello
> anymore and we will not have the latest cool features of Dale.
>

> On 14 Nov 2016, at 17:18, Cyril Ferlicot D. <[hidden email]> wrote:
>
> On 14/11/2016 15:50, Denis Kudriashov wrote:
>>
>> 2016-11-14 15:37 GMT+01:00 Esteban A. Maringolo <[hidden email]
>> <mailto:[hidden email]>>:
>>
>>    Breaking Metacello in any version = Not good.
>>
>>    Metacello is very backward compatible but breaking pragma semantics
>>    would require a rewrite of many configurations that work okay today
>>
>>
>> Why? ConfigurationOf~ not collect any pragmas by themselves. They only
>> declare versions by pragmas.
>> And we only need to fix Pharo version of Metacello which is already fork.
>
> Changes to Metacello should be done on metacello-work repository and not
> only on Pharo. Else we will not be able to load the latest Metacello
> anymore and we will not have the latest cool features of Dale.

> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
>
> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>
> Breaking Metacello in any version = Not good.
>
> Metacello is very backward compatible but breaking pragma semantics
> would require a rewrite of many configurations that work okay today
> and would require a new version of Metacello that contemplates the new
> selectors based on some criteria.
>
> Regards!
>
> Esteban A. Maringolo
>

> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
> Von: "Eliot Miranda" <[hidden email]>
> An: "Pharo Development List" <[hidden email]>
> Cc: [hidden email]
> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>
> Hi All,
>
>      can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we
>
> - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
>
> - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
>
> _,,,^..^,,,_ (phone)
>
> > On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
> >
> > 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
> >> Breaking Metacello in Pharo 6: Not good. Revert: +1
> >
> > Breaking Metacello in any version = Not good.
> >
> > Metacello is very backward compatible but breaking pragma semantics
> > would require a rewrite of many configurations that work okay today
> > and would require a new version of Metacello that contemplates the new
> > selectors based on some criteria.
> >
> > Regards!
> >
> > Esteban A. Maringolo
> >
>
>

> Le 14/11/2016 à 18:12, Denis Kudriashov a écrit :
>> But we already has fork of Metacello in image. Many Metacello packages
>> are from integrator.
>> So loading latest version is not possible now. And merge will not be
>> easy task anyway.
>> But maybe I am wrong here.
> For some projects as MaterialDesignLite I need the latest version of
> Metacello so I load it. Before the change in pragma it was fine.
>
> Dale try to keep Metacello running on Pharo with TravisCI I think.
>

> We are integrating Pragma into the GemStone base for GemStone 3.4.0, so when the dust settles over the changes I will integrate them into GemStone 3.4.0 ...
>
> Dale
>
> On 11/14/2016 11:18 AM, Torsten Bergmann wrote:
>> I was hit by this today already as it made Catalog slow like hell (which I fixed):  https://pharo.fogbugz.com/f/cases/19342/.
>>
>> +1   for the short-term revert
>> +10  for aligning Squeak and Pharo with a more intention revealing name
>>
>> Thx
>> T.
>>
>>> Gesendet: Montag, 14. November 2016 um 19:49 Uhr
>>> Von: "Eliot Miranda" <[hidden email]>
>>> An: "Pharo Development List" <[hidden email]>
>>> Cc: [hidden email]
>>> Betreff: Re: [Pharo-dev] Pragma keyword / selector / methodSelector
>>>
>>> Hi All,
>>>
>>>      can I suggest that Pharo and Squeak coordinate on a change.  First, #selector is bad because it is ambiguous.  As already determined #keyword is awful because it's false (it is a message selector, not just a keyword).  So could we
>>>
>>> - use #methodSelector and #pragmaSelector for the next few years, and deprecate #selector and #keyword?
>>>
>>> - after a suitable time use #selector to mean #pragmaSelector because that's the most useful abbreviation (in my experience I most often access #pragmaSelector)?
>>>
>>> _,,,^..^,,,_ (phone)
>>>
>>>> On Nov 14, 2016, at 6:37 AM, Esteban A. Maringolo <[hidden email]> wrote:
>>>>
>>>> 2016-11-14 11:27 GMT-03:00 [hidden email] <[hidden email]>:
>>>>> Breaking Metacello in Pharo 6: Not good. Revert: +1
>>>> Breaking Metacello in any version = Not good.
>>>>
>>>> Metacello is very backward compatible but breaking pragma semantics
>>>> would require a rewrite of many configurations that work okay today
>>>> and would require a new version of Metacello that contemplates the new
>>>> selectors based on some criteria.
>>>>
>>>> Regards!
>>>>
>>>> Esteban A. Maringolo
>>>>
>>>
>
>

>
> 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
> Here's my 2ct:
>
> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to do things (_except_ for primitive: and apicall:, but these are now  outliers).
>    They rather add metadata to a (compiled) method.
> 2. The 'thing' (ie, class) should probably be named
>         MethodAnnotation
> 3. We can have the cake and eat it to:
>
>         Rename Pragma -> MethodAnnotation.
>         Make Pragma a new subclass of MethodAnnotation.
>         Make MethodAnnotation implement
>                 #methodSelector
>                 #annotationSelector (or #selector, if it must be)
>         Make Pragma implement
>                 #selector
>                 #keywords
>
> I remember long discussion about Pragma vs Annotation name where Igor won completely :)). Conclusion was that Pragma is a right name.

> Hi Tobias, Hi Denis,
>
> On Wed, Nov 16, 2016 at 7:00 AM, Denis Kudriashov <[hidden email]> wrote:
> You force me to search archives. I hope anybody else does this :).
>
> Here is good answer why pragma instead of annotation: http://forum.world.st/Pragma-support-in-Squeak-Pharo-Cuis-td3243836.html#a3245226
>
> Thanks.  Igor gets to the technical justification; method annotations/pragmas/those funny things in angle brackets *can* tell a compiler to do things and yes, Tobias, you're right, they *are* also metadata.
>
> The /real/ answer as to why we should use Pragma rather than MethodAnnotation is explained by Wittgenstein; we use words to mean what we want them to mean.  Pragma is now a term that has been used for the Smalltalk scheme for nearly twenty years.  We had a discussion several years ago, even before the thread Denis references, where we agreed that MethodAnnotation was a better name but the effort to make the change was too great for almost all of us (myself included) and so we fell back into using Pragma, and when we write the idea up this year and I presented it at ESUG I went back to using Pragma.  It's shorter, and it means what we want it to mean, which is whatever is between those angle brackets, and whatever we make our compilers to on recognising them.
>
> While the name Pragma may not be a perfect name, it does refer exactly to what we have, and it is short, and it is current.
>

>
> 2016-11-16 15:46 GMT+01:00 H. Hirzel <[hidden email]>:
> On 11/15/16, Denis Kudriashov <[hidden email]> wrote:
> > 2016-11-15 21:58 GMT+01:00 Tobias Pape <[hidden email]>:
> >
> >> Here's my 2ct:
> >>
> >> 1. Pragmas aren't actually pragmas. They do not instruct the compiler to
> >> do things (_except_ for primitive: and apicall:, but these are now
> >> outliers).
> >>    They rather add metadata to a (compiled) method.
> >> 2. The 'thing' (ie, class) should probably be named
> >>         MethodAnnotation
> >> 3. We can have the cake and eat it to:
> >>
> >>         Rename Pragma -> MethodAnnotation.
> >>         Make Pragma a new subclass of MethodAnnotation.
> >>         Make MethodAnnotation implement
> >>                 #methodSelector
> >>                 #annotationSelector (or #selector, if it must be)
> >>         Make Pragma implement
> >>                 #selector
> >>                 #keywords
> >>
> >
> > I remember long discussion about Pragma vs Annotation name where Igor won
> > completely :)). Conclusion was that Pragma is a right name.
>
> Is there a summary of this discussion available?
>
> --Hannes
>
>
>
>
>
>
>
>
> --
> _,,,^..^,,,_
> best, Eliot