- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call for little tasks for GCI

by Stephane Ducasse

I will turn the mooc challenges into tasks. On Fri, Sep 29, 2017 at 8:29 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hernan > > What we should see is that students will barely know how to program. > So any solution is good. > I think that we should ask really simple task. > > Stef > > On Fri, Sep 29, 2017 at 7:19 AM, HernÃ¡n Morales Durand > <hernan.morales(a)gmail.com> wrote: >> Hi Jigyasa, >> >> Thank you for the invitation. I read the letter, it looks interesting >> for me to participate. >> >> However I have a question about how the students can solve the exercises. >> Are they allowed to use any library or just limited to the packages >> distributed in the standard Pharo image? >> >> Cheers, >> >> HernÃ¡n >> >> >> >> >> 2017-09-28 14:41 GMT-03:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >>> Hello hernanmd, >>> >>> Please check out the link to the repository >>> (github.com/jigyasa-grover/GCI-2017-with-Pharo) it should work for you, I >>> added you as a collaborator. >>> >>> For more details on the contest and type of tasks to be created, please >>> refer: >>> 1. Resources in the repository >>> 2. Invitation Letter >>> (http://forum.world.st/Let-s-prepare-for-Google-Code-In-2017-with-Pharo-Cons…) >>> >>> Looking forward to significant contributions from your side ! >>> >>> Best Regrads >>> Jigyasa Grover >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>> >>

Sept. 29, 2017

Re: [Pharo-dev] Call for little tasks for GCI

by Stephane Ducasse

Hernan What we should see is that students will barely know how to program. So any solution is good. I think that we should ask really simple task. Stef On Fri, Sep 29, 2017 at 7:19 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > Hi Jigyasa, > > Thank you for the invitation. I read the letter, it looks interesting > for me to participate. > > However I have a question about how the students can solve the exercises. > Are they allowed to use any library or just limited to the packages > distributed in the standard Pharo image? > > Cheers, > > HernÃ¡n > > > > > 2017-09-28 14:41 GMT-03:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: >> Hello hernanmd, >> >> Please check out the link to the repository >> (github.com/jigyasa-grover/GCI-2017-with-Pharo) it should work for you, I >> added you as a collaborator. >> >> For more details on the contest and type of tasks to be created, please >> refer: >> 1. Resources in the repository >> 2. Invitation Letter >> (http://forum.world.st/Let-s-prepare-for-Google-Code-In-2017-with-Pharo-Cons…) >> >> Looking forward to significant contributions from your side ! >> >> Best Regrads >> Jigyasa Grover >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Sept. 29, 2017

Re: [Pharo-dev] Call for little tasks for GCI

by HernÃ¡n Morales Durand

Hi Jigyasa, Thank you for the invitation. I read the letter, it looks interesting for me to participate. However I have a question about how the students can solve the exercises. Are they allowed to use any library or just limited to the packages distributed in the standard Pharo image? Cheers, HernÃ¡n 2017-09-28 14:41 GMT-03:00 Jigyasa Grover <grover.jigyasa1(a)gmail.com>: > Hello hernanmd, > > Please check out the link to the repository > (github.com/jigyasa-grover/GCI-2017-with-Pharo) it should work for you, I > added you as a collaborator. > > For more details on the contest and type of tasks to be created, please > refer: > 1. Resources in the repository > 2. Invitation Letter > (http://forum.world.st/Let-s-prepare-for-Google-Code-In-2017-with-Pharo-Cons…) > > Looking forward to significant contributions from your side ! > > Best Regrads > Jigyasa Grover > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Sept. 29, 2017

Re: [Pharo-dev] String Interpolation

by HernÃ¡n Morales Durand

Hi Sven, Is this one the similar to the #evaluate in http://www.squeaksource.com/evaluablestrings ? Cheers, HernÃ¡n 2017-09-28 11:20 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > Hi, > > I got into a little office discussion about string interpolation as it is done in different programming languages. > > In Pharo we have String>>#format: which is pretty nice. It works as follows: > > | x y | > x := 123. > y := #foo. > 'x={1} and y={2}' format: { x. y }. > > It is also possible to use a dictionary with keys, like this: > > | x y | > x := 123. > y := #foo. > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. > > But this is not true string interpolation as described in [ https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to write the value generating expressions directly inside the strings. > > Since in Pharo we add features not by extending the syntax but by adding messages I wondered if it could be done for string interpolation. The goal is to make the following work: > > | x y | > x := 123. > y := #foo. > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' interpolate. > > => 'It seems x equals 123 and y equals foo while Pi is still 3.141592653589793' > > Here is the implementation I came up with: > > String>>#interpolate > "Format the receiver by interpolating the evaluation of expressions > in between curly brackets in the context of the sender as in the following 3 oneline examples. > 'Today is {Date today}' interpolate. > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. > 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." > > | senderContext | > senderContext := thisContext sender. > ^ self class new: self size streamContents: [ :out | | stream | > stream := self readStream. > [ stream atEnd ] whileFalse: [ | currentChar | > (currentChar := stream next) == ${ > ifTrue: [ | expression result | > expression := stream upTo: $}. > result := Compiler new > evaluate: expression in: senderContext to: nil notifying: nil ifFail: [ ^ nil ] logged: false. > out nextPutAll: result asString ] > ifFalse: [ > currentChar == $\ > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next ] ] > ifFalse: [ out nextPut: currentChar ] ] ] ] > > It is a hack that could certainly be improved. And there is of course an obvious security problem. > > Thoughts ? > > Sven > >

Sept. 29, 2017

Re: [Pharo-dev] String Interpolation

by Nicolas Cellier

Hi Sven, for now it works because the context into which the block is executed still has full access to the variables and receiver of outer context from which the block is declared. But it's not necessarily the case in all dialects. In VW for example, I get nil instead of foobar #('loop on value 1 in nil' 'loop on value 2 in nil' 'loop on value 3 in nil') This is because the optimized block has its own method (a CompiledBlock) and a restricted context (a BlockContext). The receiver is the BlockClosure and this closure has no copiedValues from the outerContext and an outerContext set to nil because some analyzer in the compilation phase thought the closure would never access the outerContext (no return to outerContext) nor any of its variable. Once we'll have clean blocks - depending on the implementation - things might change in Pharo too. But we must ask Clement on this subject (I add not taken time to check the implementation he proposes). 2017-09-28 19:03 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > > > On 28 Sep 2017, at 18:50, Nicolas Cellier <nicolas.cellier.aka.nice@ > gmail.com> wrote: > > > > > > > > 2017-09-28 16:20 GMT+02:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > > Hi, > > > > I got into a little office discussion about string interpolation as it > is done in different programming languages. > > > > In Pharo we have String>>#format: which is pretty nice. It works as > follows: > > > > | x y | > > x := 123. > > y := #foo. > > 'x={1} and y={2}' format: { x. y }. > > > > It is also possible to use a dictionary with keys, like this: > > > > | x y | > > x := 123. > > y := #foo. > > 'x={x} and y={y}' format: { #x->x. #y->y } asDictionary. > > > > But this is not true string interpolation as described in [ > https://en.wikipedia.org/wiki/String_interpolation ]. The idea is to > write the value generating expressions directly inside the strings. > > > > Since in Pharo we add features not by extending the syntax but by adding > messages I wondered if it could be done for string interpolation. The goal > is to make the following work: > > > > | x y | > > x := 123. > > y := #foo. > > 'It seems x equals {x} and y equals {y} while Pi is still {Float pi}' > interpolate. > > > > => 'It seems x equals 123 and y equals foo while Pi is still > 3.141592653589793' > > > > Here is the implementation I came up with: > > > > String>>#interpolate > > "Format the receiver by interpolating the evaluation of expressions > > in between curly brackets in the context of the sender as in the > following 3 oneline examples. > > 'Today is {Date today}' interpolate. > > | x | x := 123. 'x equals {x} and pi equals {Float pi}' interpolate. > > 'In {#strings} you can escape \{ by prefixing it with \\' interpolate." > > > > | senderContext | > > senderContext := thisContext sender. > > ^ self class new: self size streamContents: [ :out | | stream | > > stream := self readStream. > > [ stream atEnd ] whileFalse: [ | currentChar | > > (currentChar := stream next) == ${ > > ifTrue: [ | expression result | > > expression := stream upTo: $}. > > result := Compiler new > > evaluate: expression in: senderContext to: nil notifying: > nil ifFail: [ ^ nil ] logged: false. > > out nextPutAll: result asString ] > > ifFalse: [ > > currentChar == $\ > > ifTrue: [ stream atEnd ifFalse: [ out nextPut: stream next > ] ] > > ifFalse: [ out nextPut: currentChar ] ] ] ] > > > > It is a hack that could certainly be improved. And there is of course an > obvious security problem. > > > > Thoughts ? > > > > Sven > > > > > > Nice! > > The only objection I see is that it may fail in blocks if they don't > know that they have to refer to outer context, especially once we have > clean blocks > > Yes, there are probably some edge cases. Error handling is tricky too. > > > | outer | > > outer := 'foobar'. > > ^#( 1 2 3 ) collect: [:x | 'loop on value {x} in {outer}' interpolate] > > That example works for me in a Playground. How does it fail for you ? >

Sept. 28, 2017

Re: [Pharo-dev] Iceberg Contribution Barrier

by Sean P. DeNigris

EstebanLM wrote > you do not need to update Iceberg Aha! After I successfully navigate your other instructions I'll update the readme EstebanLM wrote > I didnât submit the change because I donât know how to fork the wiki :P If it's the "official" way, should we just move it somewhere under the team? ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Sept. 28, 2017

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

by Stephane Ducasse

Indeed we could. Coudl you add an issue? On Thu, Sep 28, 2017 at 12:43 PM, Torsten Bergmann <astares(a)gmx.de> 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" <estebanlm(a)gmail.com> > An: "Pharo Development List" <pharo-dev(a)lists.pharo.org> > Betreff: Re: [Pharo-dev] Maybe better pinning messages? (inspired by [Pinning Objects in Pharo]) > > > > On 28 Sep 2017, at 10:01, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> wrote: > > So it is integrated it Pharo 7 > > 2017-09-18 11:09 GMT+02:00 Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: > 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 <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: > > > On Sep 14, 2017, at 7:07 AM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: > > > > > Am 14.09.2017 um 10:17 schrieb Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: > > > 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 <hannes.hirzel@gmail.com[mailto:hannes.hirzel@gmail.com]>:+1 for pinInMemory > > It explains what it does. > > On 9/14/17, Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]> wrote: >> Hi Norbert, >> >>> On Sep 13, 2017, at 3:18 PM, Norbert Hartl <norbert@hartl.name[mailto:norbert@hartl.name]> wrote: >>> >>> >>>> Am 14.09.2017 um 00:09 schrieb Eliot Miranda <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>>> >>>> Hi Denis, >>>> >>>> On Tue, Sep 12, 2017 at 9:29 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>> 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 <eliot.miranda@gmail.com[mailto:eliot.miranda@gmail.com]>: >>>>>> Hi Denis, >>>>>> >>>>>> >>>>>>> On Sep 12, 2017, at 2:39 AM, Denis Kudriashov <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>>>>> 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 <estebanlm@gmail.com[mailto:estebanlm@gmail.com]>: >>>>>>>> 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 <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Anybody else? >>>>>>>>> >>>>>>>>> 2017-08-31 10:29 GMT+02:00 Pavel Krivanek >>>>>>>>> <pavel.krivanek@gmail.com[mailto:pavel.krivanek@gmail.com]>: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2017-08-31 10:24 GMT+02:00 Denis Kudriashov >>>>>>>>>> <dionisiydk@gmail.com[mailto:dionisiydk@gmail.com]>: >>>>>>>>>>> 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 >>> >> > >

Sept. 28, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Stephane Ducasse

Thanks On Thu, Sep 28, 2017 at 6:36 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-09-28 18:17 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-09-25 17:57 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >> >>> 2017-09-25 17:38 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >>> >>>> I agree with guille. We should just called them class annotations. >>>> >>>> Denis what is a declared instance (is it an object returned by the >>>> method having the annotation) >>>> but can we find a better name. >>>> >>> >>> My idea that the method with pragma #classMetaAnnotation is the >>> declaration of annotation. Internally this declaration creates instance of >>> specified annotation which cached by system. And users access all these >>> declared instances for reflection purposes. >>> >>> >> Maybe #registeredInstances would be better? >> > > So I rename these messages too. I think it's better. > > >> >>> Also annotation has inst var declarationSelector. >>> >> >>> >>>> may be effectiveInstances? >>>> >>> >>> I don't like this name. I not understand "effective" in that context. >>> >>> >>>> >>>> >>>> On Mon, Sep 25, 2017 at 5:09 PM, Guillermo Polito < >>>> guillermopolito(a)gmail.com> wrote: >>>> >>>>> Why calling them meta-annotation and not just annotation? Annotations >>>>> are in general already meta :) >>>>> >>>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov < >>>>> dionisiydk(a)gmail.com> wrote: >>>>> >>>>>> Hi. >>>>>> >>>>>> I glad to present one class package which introduces reusable >>>>>> mechanism for first class annotations. >>>>>> >>>>>> The project can be found on github https://github.com/dion >>>>>> isiydk/ClassMetaAnnotation. >>>>>> And I tried to describe why it is needed in my blog >>>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>>> >>>>>> And here is overview: >>>>>> >>>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>>> it to class you create new class side method which will return an instance >>>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>>> >>>>>> >>>>>> MyClass class>>specialAnnotation >>>>>> >>>>>> <classMetaAnnotation> >>>>>> >>>>>> ^MySpecialAnnotation new >>>>>> >>>>>> >>>>>> To query annotations from system there are two methods: >>>>>> >>>>>> 1) You can ask concrete annotation class for all declared instances: >>>>>> >>>>>> MySpecialAnnotation declaredInstances >>>>>> >>>>>> 2) You can ask given class for all attached annotations: >>>>>> >>>>>> MyClass metaAnnotations >>>>>> >>>>>> Every annotation includes information about annotated class and the >>>>>> selector of declaring method. >>>>>> All annotations are cached. So it is cheap to query them. There are >>>>>> extra messages to enumerate annotations using block. >>>>>> >>>>>> Now let's discuss it. I think it can be good addition for the Pharo >>>>>> 7. Especially that it is very small code. >>>>>> >>>>>> Also I would like to thank Marcus who helps me realize this concept >>>>>> in Commander and Calypso which I start simplify with this library. >>>>>> >>>>>> Best regards, >>>>>> Denis >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> Guille Polito >>>>> >>>>> Research Engineer >>>>> >>>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>>> >>>>> CRIStAL - UMR 9189 >>>>> >>>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>>> <http://www.cnrs.fr>* >>>>> >>>>> >>>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>>> >>>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>>> >>>> >>>> >>> >> >

Sept. 28, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Stephane Ducasse

Yes. On Thu, Sep 28, 2017 at 6:17 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > 2017-09-25 17:57 GMT+02:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > >> 2017-09-25 17:38 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> I agree with guille. We should just called them class annotations. >>> >>> Denis what is a declared instance (is it an object returned by the >>> method having the annotation) >>> but can we find a better name. >>> >> >> My idea that the method with pragma #classMetaAnnotation is the >> declaration of annotation. Internally this declaration creates instance of >> specified annotation which cached by system. And users access all these >> declared instances for reflection purposes. >> >> > Maybe #registeredInstances would be better? > > >> Also annotation has inst var declarationSelector. >> > >> >>> may be effectiveInstances? >>> >> >> I don't like this name. I not understand "effective" in that context. >> >> >>> >>> >>> On Mon, Sep 25, 2017 at 5:09 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Why calling them meta-annotation and not just annotation? Annotations >>>> are in general already meta :) >>>> >>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Hi. >>>>> >>>>> I glad to present one class package which introduces reusable >>>>> mechanism for first class annotations. >>>>> >>>>> The project can be found on github https://github.com/dion >>>>> isiydk/ClassMetaAnnotation. >>>>> And I tried to describe why it is needed in my blog >>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>> >>>>> And here is overview: >>>>> >>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>> it to class you create new class side method which will return an instance >>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>> >>>>> >>>>> MyClass class>>specialAnnotation >>>>> >>>>> <classMetaAnnotation> >>>>> >>>>> ^MySpecialAnnotation new >>>>> >>>>> >>>>> To query annotations from system there are two methods: >>>>> >>>>> 1) You can ask concrete annotation class for all declared instances: >>>>> >>>>> MySpecialAnnotation declaredInstances >>>>> >>>>> 2) You can ask given class for all attached annotations: >>>>> >>>>> MyClass metaAnnotations >>>>> >>>>> Every annotation includes information about annotated class and the >>>>> selector of declaring method. >>>>> All annotations are cached. So it is cheap to query them. There are >>>>> extra messages to enumerate annotations using block. >>>>> >>>>> Now let's discuss it. I think it can be good addition for the Pharo 7. >>>>> Especially that it is very small code. >>>>> >>>>> Also I would like to thank Marcus who helps me realize this concept in >>>>> Commander and Calypso which I start simplify with this library. >>>>> >>>>> Best regards, >>>>> Denis >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >

Sept. 28, 2017

Re: [Pharo-dev] [Ann] Class meta annotations

by Stephane Ducasse

I would not use meta because you would not write annotationAnnotations :) and annotations is meta by its name. classAnnotation is much better than metaAnnotation Stef On Thu, Sep 28, 2017 at 5:40 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > So I renamed it to ClassAnnotation with all related names. > > But I keep meta prefix in #metaAnnotations Class extension to avoid > general name: > > MyClass metaAnnotations > > You can check updated readme for details https://github.com/ > dionisiydk/ClassAnnotation > > 2017-09-26 17:31 GMT+02:00 Stephane Ducasse <stepharo.self(a)gmail.com>: > >> ;) >> >> On Tue, Sep 26, 2017 at 1:28 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >>> Shhh... The first rule of meta-club is we don't talk about meta-club. >>> >>> >>> cheers -ben >>> >>> >>> On Mon, Sep 25, 2017 at 11:09 PM, Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Why calling them meta-annotation and not just annotation? Annotations >>>> are in general already meta :) >>>> >>>> On Mon, Sep 25, 2017 at 5:01 PM, Denis Kudriashov <dionisiydk(a)gmail.com >>>> > wrote: >>>> >>>>> Hi. >>>>> >>>>> I glad to present one class package which introduces reusable >>>>> mechanism for first class annotations. >>>>> >>>>> The project can be found on github https://github.com/dion >>>>> isiydk/ClassMetaAnnotation. >>>>> And I tried to describe why it is needed in my blog >>>>> http://dionisiydk.blogspot.fr/2017/09/class-meta-annotations.html. >>>>> >>>>> And here is overview: >>>>> >>>>> Every annotation should be subclass of ClassMetaAnnotation. To attach >>>>> it to class you create new class side method which will return an instance >>>>> of the annotation. Method should be marked with pragma #classMetaAnnotation: >>>>> >>>>> >>>>> MyClass class>>specialAnnotation >>>>> >>>>> <classMetaAnnotation> >>>>> >>>>> ^MySpecialAnnotation new >>>>> >>>>> >>>>> To query annotations from system there are two methods: >>>>> >>>>> 1) You can ask concrete annotation class for all declared instances: >>>>> >>>>> MySpecialAnnotation declaredInstances >>>>> >>>>> 2) You can ask given class for all attached annotations: >>>>> >>>>> MyClass metaAnnotations >>>>> >>>>> Every annotation includes information about annotated class and the >>>>> selector of declaring method. >>>>> All annotations are cached. So it is cheap to query them. There are >>>>> extra messages to enumerate annotations using block. >>>>> >>>>> Now let's discuss it. I think it can be good addition for the Pharo 7. >>>>> Especially that it is very small code. >>>>> >>>>> Also I would like to thank Marcus who helps me realize this concept in >>>>> Commander and Calypso which I start simplify with this library. >>>>> >>>>> Best regards, >>>>> Denis >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> Guille Polito >>>> >>>> Research Engineer >>>> >>>> Centre de Recherche en Informatique, Signal et Automatique de Lille >>>> >>>> CRIStAL - UMR 9189 >>>> >>>> French National Center for Scientific Research - *http://www.cnrs.fr >>>> <http://www.cnrs.fr>* >>>> >>>> >>>> *Web:* *http://guillep.github.io* <http://guillep.github.io> >>>> >>>> *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >>>> >>> >>> >> >

Sept. 28, 2017