February 2018 - Pharo-users

Re: [Pharo-users] [ANN] 15/2: Pharo TechTalk: Contributing to Pharo 7

by Marcus Denker

> On 13 Feb 2018, at 13:03, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Pharo TechTalk: Contributing to Pharo 7 > > When? 15 Feb 2018 5:00 PM - 7:00 PM (UTC+01:00) > What? Contributing to Pharo7 > > We will show: > - How to submit issue tracker entries to the Pharo Issue Tracker > - How to do a Pull Request if you want to do a fix or enhancment > - How to review and comment other peoples fixes. > > https://association.pharo.org/event-2797065 > > Future TechTalks: â¢ March 29: Report 2017 Pharo Consortium and Association. https://association.pharo.org/event-2797067 <https://association.pharo.org/event-2797067> **DATE CHANGED from 22 to 29** â¢ April 12: Pillar. https://association.pharo.org/event-2797068 <https://association.pharo.org/event-2797068> â¢ May 17: TBA â¢ June 14 TBA TBA â> Open Slot. Please send suggestions! Marcus

Feb. 13, 2018

Pillar questions

by Arturo Zambrano

Hi All, Q1 Is there a way of adding page headers/footers in pillar? header = image + short legend. footer = line + section name + page number. Q2 My plan is to use Pillar programmatically, are you aware of some projects that use Pillar in that way? Most of the documentation I found is regarding Pillar syntax. The testcases are good examples, but I would like to see something more complex if possible. Thanks! Arturo

Feb. 13, 2018

Re: [Pharo-users] Roassal to ODG

by Arturo Zambrano

On Tue, Feb 13, 2018 at 7:27 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > So I want to re post my question: > > "What is the best option to generate an editable flow chart from Pharo > (Roassal)?â > > There are none as far as I know. However, this is something that can be > done (rather easily I would say). > Thanks, any direction? > > Alexandre >

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Herbert VojÄÃk

Denis Kudriashov wrote: > > 2018-02-13 10:25 GMT+01:00 Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>>: > > Sometimes I think we should treat globals more in a âlate boundâ > fashion. > > e.g. right now we say that âUndeclaredâ vars are to be avoided at > any cost. > > But we could just treat them like we treat messages that are send > that do not exist. > > Forcing â#classNamed: â for all unknown globals is a bit similar > than forcing to use âperform:â for > all unknown selectors. > > e.g. why have Smalltalk at: #SomeClass and react to it if you could > instead reason on the fact that > a variable is not bound (yet). > > SomeGlobal ifUndefined: [ ]. > > > I really like this idea. We just need to represent undefined variable > value as special object instead of nil. I don't like it for precisely this. In JS, there is undefined and null, and everyone hates that (despite maybe good intentions to split the two meanings). #SomeGlobal inContextOf: self ifUndefined: [ ... ] Maybe this could go if enough magic is done, though: [ SomeGlobal ] ifUndefined: [ ... ] > This way we would not obscure the fact that we are accessing a > global and we model explicitly the state > if it is bound or not. > > Would that no be better than hiding it behind an API to look up symbols? > > (just some thoughts, needs more thinking before action is possible) > > Marcus > >> On 11 Feb 2018, at 22:12, Richard Sargent >> <richard.sargent(a)gemtalksystems.com >> <mailto:richard.sargent@gemtalksystems.com>> wrote: >> >> There are two use cases that come immediately to mind. They may be >> the two most important. >> >> "As a Compiler, I need to be able to resolve a Symbol to a known >> Object." >> "As a Browser, I need to be able to identify the possible >> resolutions of a String to known Objects." >> >> >> I can elaborate on those, but I think they are pretty clear no >> matter what scopes, namespaces, environments, modules, or whatever >> one uses to organize things in the image. (One can even imagine an >> external registry of names that could be searched and yield up >> suggestions of external packages that would be needed.) >> >> On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> >> >> >> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse >> <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>>: >> >> Denis >> >> we should introduce classNamed: now we can have traits and >> globals too :( >> >> >> Yes, we need to think about it. >> >> Idea? may be can still classNamed: >> >> Stef >> >> >> On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>> wrote: >> > >> > >> > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand >> <hernan.morales(a)gmail.com <mailto:hernan.morales@gmail.com>>: >> >> >> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> > Hi Hernan. >> >> > >> >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand >> >> > <hernan.morales(a)gmail.com >> <mailto:hernan.morales@gmail.com>>: >> >> >> >> >> >> Hi Denis >> >> >> >> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov >> <dionisiydk(a)gmail.com <mailto:dionisiydk@gmail.com>>: >> >> >> > >> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >> >> >> > <stepharo.self(a)gmail.com >> <mailto:stepharo.self@gmail.com>>: >> >> >> >> >> >> >> >> Please to not use an unary on Symbol >> >> >> >> Dispatch on something. >> >> >> >> >> >> >> >> self class environment at: #Array >> >> >> >> is the best >> >> >> > >> >> >> > >> >> >> > We should not use collection API for reflection >> calls. It makes them >> >> >> > very >> >> >> > difficult to find. Let's use explicit names like: >> >> >> > >> >> >> >> >> >> Sorry I do not see it. >> >> >> >> >> >> The Collection API is beautiful, why couldn't be >> used for reflection? >> >> > >> >> > >> >> > We have around 3000 senders of #at: message in the >> image. Do you think >> >> > it is >> >> > easy to filter reflective calls? >> >> > >> >> >> >> I still don't understand your use case, nor how the >> #at: is related >> >> with the #asClass issue. >> >> >> >> Do you mean **further** filtering for relflective sends? >> >> >> >> Does this affects common-usage beyond Browser development? >> > >> > >> > The Stef proposal was that we should never use #asClass >> in the code. It is >> > fine for scripting but not for the domain code by many >> reasons which were >> > discussed here and at the past. >> > >> > But I only commented the proposed replacement: >> > >> > self class environment at: #Object >> > >> > >> > If you do not like it, it is different story. I just >> described problem with >> > #at: message: >> > >> > We already replaced many #asClass users with this code. >> And now it is quite >> > difficult to find such places. They all hidden inside >> 3000 senders of #at:. >> > If we will use #classNamed: instead of #at: then simple >> senders query will >> > easily detect all reflective calls. >> > (we probably already use it but not in all places). >> > >> >> >> >> >> >> >> >> >> >> I have no trouble finding #asClass senders, >> implementors, etc. >> >> >> >> >> >> What do you want to find? >> >> >> >> >> >> > self class environment classNamed: #Array >> >> >> > >> >> >> >> >> >> Too much typing :) >> >> >> >> >> >> > >> >> >> > From the other side we all agree that #asClass is >> super handy method. >> >> >> > And we >> >> >> > can fix it to respect sender environment using >> thisContext. It will >> >> >> > affects >> >> >> > performance but with our super powerful metalinks >> it can be easily >> >> >> > cached >> >> >> > (#asMethodConst is implemented that way). >> >> >> > So we can make environment completely transparent >> for users. >> >> >> > >> >> >> > Best regards, >> >> >> > Denis >> >> >> > >> >> >> >> >> >> >> >> For Modules, we made progress and got bitten by >> many issues and >> >> >> >> teaching >> >> >> >> load. >> >> >> >> >> >> >> >> >> >> >> >> Stef >> >> >> >> >> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera >> >> >> >> <bera.clement(a)gmail.com >> <mailto:bera.clement@gmail.com>> >> >> >> >> wrote: >> >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales >> Durand >> >> >> >> > <hernan.morales(a)gmail.com >> <mailto:hernan.morales@gmail.com>> wrote: >> >> >> >> >> >> >> >> >> >> Hi ClÃ©ment, >> >> >> >> >> >> >> >> >> >> First time I read about modules in Pharo. >> >> >> >> >> What is a module exactly? >> >> >> >> >> >> >> >> >> >> What's the problem to solve? >> >> >> >> > >> >> >> >> > >> >> >> >> > It's similar to namespaces with some different, >> arguably better, >> >> >> >> > features. >> >> >> >> > >> >> >> >> > Honestly I am not the expert on it so I would >> like some one else >> >> >> >> > to >> >> >> >> > answer. >> >> >> >> > >> >> >> >> > Among other things, it solves the problem of >> having 2 classes with >> >> >> >> > the >> >> >> >> > same >> >> >> >> > name (avoiding the prefixes we have like in C). >> But reportedly >> >> >> >> > that's >> >> >> >> > just a >> >> >> >> > side-effect and not the main problem to solve. >> >> >> >> > >> >> >> >> >> >> >> >> >> >> Cheers, >> >> >> >> >> >> >> >> >> >> HernÃ¡n >> >> >> >> >> >> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera >> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >> >> >> >> >> > Hi, >> >> >> >> >> > >> >> >> >> >> > In short, everything that is not >> namespace/module compatible >> >> >> >> >> > will >> >> >> >> >> > be >> >> >> >> >> > deprecated/changed/removed in the future, so >> it is not >> >> >> >> >> > recommended >> >> >> >> >> > to >> >> >> >> >> > use >> >> >> >> >> > it. >> >> >> >> >> > >> >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk >> globals >> >> >> >> >> > b.1) Smalltalk globals at: #Array >> >> >> >> >> > => Ok-ish, note that you may need to change >> 'Smalltalk globals' >> >> >> >> >> > the >> >> >> >> >> > namespace/module when support for those will >> be added since >> >> >> >> >> > Array >> >> >> >> >> > will >> >> >> >> >> > be in >> >> >> >> >> > a module. >> >> >> >> >> > Maybe you want instead to use instead: >> >> >> >> >> > >> >> >> >> >> > c) self class environment at: #Array >> >> >> >> >> > => this will work in the future if your code >> is a class which >> >> >> >> >> > environment/namespace/module includes the >> Array class you would >> >> >> >> >> > expect >> >> >> >> >> > >> >> >> >> >> > a.1) #Array asClass >> >> >> >> >> > b.2) Smalltalk at: #Array >> >> >> >> >> > b.3) Smalltalk classNamed: #Array >> >> >> >> >> > => In which namespace/module are you looking >> for #Array ? In >> >> >> >> >> > the >> >> >> >> >> > future >> >> >> >> >> > this >> >> >> >> >> > may be removed, alternatively it will work >> only for globals but >> >> >> >> >> > not >> >> >> >> >> > globals >> >> >> >> >> > inside namespace/module which won't work >> since Array will be in >> >> >> >> >> > a >> >> >> >> >> > module. >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k >> >> >> >> >> > <i.uhnak(a)gmail.com <mailto:i.uhnak@gmail.com>> >> >> >> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> Hi, >> >> >> >> >> >> >> >> >> >> >> >> what is the canonical way to get a class >> from a symbol? >> >> >> >> >> >> >> >> >> >> >> >> a) Converting symbol into class via string >> protocol >> >> >> >> >> >> >> >> >> >> >> >> a.1) #Array asClass >> >> >> >> >> >> I use this the most, because it is easy, >> uses unary selector, >> >> >> >> >> >> and >> >> >> >> >> >> so >> >> >> >> >> >> far >> >> >> >> >> >> I've never ran into any issues. But >> apparently it is not good >> >> >> >> >> >> -- >> >> >> >> >> >> why? >> >> >> >> >> >> >> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk >> globals >> >> >> >> >> >> >> >> >> >> >> >> b) Retriving the class by key from the >> system dictionary >> >> >> >> >> >> >> >> >> >> >> >> b.1) Smalltalk globals at: #Array >> >> >> >> >> >> >> >> >> >> >> >> b.2) Smalltalk at: #Array >> >> >> >> >> >> >> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >> >> >> >> >> >> >> >> >> >> >> >> c) something else entirely? >> >> >> >> >> >> >> >> >> >> >> >> I get that using #asClass wouldn't work if >> there was a >> >> >> >> >> >> different >> >> >> >> >> >> environment, however I don't even know in >> what situation there >> >> >> >> >> >> could >> >> >> >> >> >> be >> >> >> >> >> >> a >> >> >> >> >> >> different environment, so I cannot assert >> how problematic it >> >> >> >> >> >> is >> >> >> >> >> >> or >> >> >> >> >> >> isn't. >> >> >> >> >> >> >> >> >> >> >> >> Thanks, >> >> >> >> >> >> Peter >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > >> >> >> >> >> > -- >> >> >> >> >> > ClÃ©ment BÃ©ra >> >> >> >> >> > Pharo consortium engineer >> >> >> >> >> > https://clementbera.wordpress.com/ >> <https://clementbera.wordpress.com/> >> >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 >> Villeneuve d >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…>' >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…>Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >> >> >> >> >> >> >> >> >> > >> >> >> >> > >> >> >> >> > >> >> >> >> > -- >> >> >> >> > ClÃ©ment BÃ©ra >> >> >> >> > Pharo consortium engineer >> >> >> >> > https://clementbera.wordpress.com/ >> <https://clementbera.wordpress.com/> >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…>' >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…>Ascq >> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >> >> >> >> >> >> >> > >> >> >> >> >> > >> >> >> > >> >> >> > >

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Sven Van Caekenberghe

> On 13 Feb 2018, at 13:12, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Sven Van Caekenberghe-2 wrote >> There is also ZnHtmlOutputStream (a simple helper class) for generating >> syntactically correct HTML. > > Yes, it's nice. I've used it in images when I needed to work with HTML > without Seaside loaded. It is way simpler though, Seaside's model is much better (but consists of lots of classes). YMMV

Feb. 13, 2018

Re: [Pharo-users] [Iliad] raw HTML in Iliad

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > There is also ZnHtmlOutputStream (a simple helper class) for generating > syntactically correct HTML. Yes, it's nice. I've used it in images when I needed to work with HTML without Seaside loaded. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Sean P. DeNigris

Marcus Denker-4 wrote > Sometimes I think we should treat globals more in a âlate boundâ fashion. Late bound = power. I remember being very disappointed when I realized that classes are early bound by methods (resolved in literals). This makes things like class-side stubbing very difficult without jumping through hoops (e.g. process variables). ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Feb. 13, 2018

[ANN] 15/2: Pharo TechTalk: Contributing to Pharo 7

by Marcus Denker

Pharo TechTalk: Contributing to Pharo 7 When? 15 Feb 2018 5:00 PM - 7:00 PM (UTC+01:00) What? Contributing to Pharo7 We will show: - How to submit issue tracker entries to the Pharo Issue Tracker - How to do a Pull Request if you want to do a fix or enhancment - How to review and comment other peoples fixes. https://association.pharo.org/event-2797065

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Marcus Denker

> On 13 Feb 2018, at 11:32, Ben Coman <btc(a)openinworld.com> wrote: > > > > On 13 February 2018 at 17:25, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Sometimes I think we should treat globals more in a âlate boundâ fashion. > > > This may remove a big reason for needing asClass, which was introduced so you could DoIt > on a script to load a package and then operate on a class from that package before that class was defined. > > > e.g. right now we say that âUndeclaredâ vars are to be avoided at any cost. > > But we could just treat them like we treat messages that are send that do not exist. > > Forcing â#classNamed: â for all unknown globals is a bit similar than forcing to use âperform:â for > all unknown selectors. > > e.g. why have Smalltalk at: #SomeClass and react to it if you could instead reason on the fact that > a variable is not bound (yet). > > SomeGlobal ifUndefined: [ ]. > > This way we would not obscure the fact that we are accessing a global and we model explicitly the state > if it is bound or not. > > I guess its partially a compiler issue. One way would be for the compiler to wrap the reference > to SomeGlobal in an instance of UnknownGlobal. When a message is sent to that instance, > it can check whether SomeGlobal is now defined (i.e. loaded earlier in the script) and forward the message to SomeGlobal. > The current Undeclared mechanism should make it easy: for every Undeclared, we do have a binding in Undeclared that binds the name to nil. Could be another value (some first class object). Maybe it could even put as the value the binging itself, which is already a subclass of Association called UndeclaredVariable. Marcus

Feb. 13, 2018

Re: [Pharo-users] canonical way to convert Symbol into Class (retrieve class by its name)

by Ben Coman

On 13 February 2018 at 17:25, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Sometimes I think we should treat globals more in a âlate boundâ fashion. > > This may remove a big reason for needing asClass, which was introduced so you could DoIt on a script to load a package and then operate on a class from that package before that class was defined. > e.g. right now we say that âUndeclaredâ vars are to be avoided at any cost. > > But we could just treat them like we treat messages that are send that do > not exist. > > Forcing â#classNamed: â for all unknown globals is a bit similar than > forcing to use âperform:â for > all unknown selectors. > > e.g. why have Smalltalk at: #SomeClass and react to it if you could > instead reason on the fact that > a variable is not bound (yet). > > SomeGlobal ifUndefined: [ ]. > > This way we would not obscure the fact that we are accessing a global and > we model explicitly the state > if it is bound or not. > I guess its partially a compiler issue. One way would be for the compiler to wrap the reference to SomeGlobal in an instance of UnknownGlobal. When a message is sent to that instance, it can check whether SomeGlobal is now defined (i.e. loaded earlier in the script) and forward the message to SomeGlobal. > > Would that no be better than hiding it behind an API to look up symbols? > > yes. cheers -ben > (just some thoughts, needs more thinking before action is possible) > > Marcus > > On 11 Feb 2018, at 22:12, Richard Sargent <richard.sargent@ > gemtalksystems.com> wrote: > > There are two use cases that come immediately to mind. They may be the two > most important. > > "As a Compiler, I need to be able to resolve a Symbol to a known Object." > "As a Browser, I need to be able to identify the possible resolutions of a > String to known Objects." > > > I can elaborate on those, but I think they are pretty clear no matter what > scopes, namespaces, environments, modules, or whatever one uses to organize > things in the image. (One can even imagine an external registry of names > that could be searched and yield up suggestions of external packages that > would be needed.) > > On Sun, Feb 11, 2018 at 12:42 PM, Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> >> >> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.self(a)gmail.com>: >> >>> Denis >>> >>> we should introduce classNamed: now we can have traits and globals too :( >>> >> >> Yes, we need to think about it. >> >> >>> Idea? may be can still classNamed: >>> >>> Stef >>> >>> >>> On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> > >>> > >>> > 2018-02-11 20:36 GMT+01:00 HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com>: >>> >> >>> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com>: >>> >> > Hi Hernan. >>> >> > >>> >> > 2018-02-11 19:57 GMT+01:00 HernÃ¡n Morales Durand >>> >> > <hernan.morales(a)gmail.com>: >>> >> >> >>> >> >> Hi Denis >>> >> >> >>> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk(a)gmail.com >>> >: >>> >> >> > >>> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >>> >> >> > <stepharo.self(a)gmail.com>: >>> >> >> >> >>> >> >> >> Please to not use an unary on Symbol >>> >> >> >> Dispatch on something. >>> >> >> >> >>> >> >> >> self class environment at: #Array >>> >> >> >> is the best >>> >> >> > >>> >> >> > >>> >> >> > We should not use collection API for reflection calls. It makes >>> them >>> >> >> > very >>> >> >> > difficult to find. Let's use explicit names like: >>> >> >> > >>> >> >> >>> >> >> Sorry I do not see it. >>> >> >> >>> >> >> The Collection API is beautiful, why couldn't be used for >>> reflection? >>> >> > >>> >> > >>> >> > We have around 3000 senders of #at: message in the image. Do you >>> think >>> >> > it is >>> >> > easy to filter reflective calls? >>> >> > >>> >> >>> >> I still don't understand your use case, nor how the #at: is related >>> >> with the #asClass issue. >>> >> >>> >> Do you mean **further** filtering for relflective sends? >>> >> >>> >> Does this affects common-usage beyond Browser development? >>> > >>> > >>> > The Stef proposal was that we should never use #asClass in the code. >>> It is >>> > fine for scripting but not for the domain code by many reasons which >>> were >>> > discussed here and at the past. >>> > >>> > But I only commented the proposed replacement: >>> > >>> > self class environment at: #Object >>> > >>> > >>> > If you do not like it, it is different story. I just described problem >>> with >>> > #at: message: >>> > >>> > We already replaced many #asClass users with this code. And now it is >>> quite >>> > difficult to find such places. They all hidden inside 3000 senders of >>> #at:. >>> > If we will use #classNamed: instead of #at: then simple senders query >>> will >>> > easily detect all reflective calls. >>> > (we probably already use it but not in all places). >>> > >>> >> >>> >> >>> >> >> >>> >> >> I have no trouble finding #asClass senders, implementors, etc. >>> >> >> >>> >> >> What do you want to find? >>> >> >> >>> >> >> > self class environment classNamed: #Array >>> >> >> > >>> >> >> >>> >> >> Too much typing :) >>> >> >> >>> >> >> > >>> >> >> > From the other side we all agree that #asClass is super handy >>> method. >>> >> >> > And we >>> >> >> > can fix it to respect sender environment using thisContext. It >>> will >>> >> >> > affects >>> >> >> > performance but with our super powerful metalinks it can be >>> easily >>> >> >> > cached >>> >> >> > (#asMethodConst is implemented that way). >>> >> >> > So we can make environment completely transparent for users. >>> >> >> > >>> >> >> > Best regards, >>> >> >> > Denis >>> >> >> > >>> >> >> >> >>> >> >> >> For Modules, we made progress and got bitten by many issues and >>> >> >> >> teaching >>> >> >> >> load. >>> >> >> >> >>> >> >> >> >>> >> >> >> Stef >>> >> >> >> >>> >> >> >> On Sat, Feb 10, 2018 at 4:50 PM, ClÃ©ment Bera >>> >> >> >> <bera.clement(a)gmail.com> >>> >> >> >> wrote: >>> >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, HernÃ¡n Morales Durand >>> >> >> >> > <hernan.morales(a)gmail.com> wrote: >>> >> >> >> >> >>> >> >> >> >> Hi ClÃ©ment, >>> >> >> >> >> >>> >> >> >> >> First time I read about modules in Pharo. >>> >> >> >> >> What is a module exactly? >>> >> >> >> >> >>> >> >> >> >> What's the problem to solve? >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > It's similar to namespaces with some different, arguably >>> better, >>> >> >> >> > features. >>> >> >> >> > >>> >> >> >> > Honestly I am not the expert on it so I would like some one >>> else >>> >> >> >> > to >>> >> >> >> > answer. >>> >> >> >> > >>> >> >> >> > Among other things, it solves the problem of having 2 classes >>> with >>> >> >> >> > the >>> >> >> >> > same >>> >> >> >> > name (avoiding the prefixes we have like in C). But reportedly >>> >> >> >> > that's >>> >> >> >> > just a >>> >> >> >> > side-effect and not the main problem to solve. >>> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> Cheers, >>> >> >> >> >> >>> >> >> >> >> HernÃ¡n >>> >> >> >> >> >>> >> >> >> >> 2018-02-10 9:47 GMT-03:00 ClÃ©ment Bera < >>> bera.clement(a)gmail.com>: >>> >> >> >> >> > Hi, >>> >> >> >> >> > >>> >> >> >> >> > In short, everything that is not namespace/module >>> compatible >>> >> >> >> >> > will >>> >> >> >> >> > be >>> >> >> >> >> > deprecated/changed/removed in the future, so it is not >>> >> >> >> >> > recommended >>> >> >> >> >> > to >>> >> >> >> >> > use >>> >> >> >> >> > it. >>> >> >> >> >> > >>> >> >> >> >> > a.2) #Array asClassInEnvironment: Smalltalk globals >>> >> >> >> >> > b.1) Smalltalk globals at: #Array >>> >> >> >> >> > => Ok-ish, note that you may need to change 'Smalltalk >>> globals' >>> >> >> >> >> > the >>> >> >> >> >> > namespace/module when support for those will be added since >>> >> >> >> >> > Array >>> >> >> >> >> > will >>> >> >> >> >> > be in >>> >> >> >> >> > a module. >>> >> >> >> >> > Maybe you want instead to use instead: >>> >> >> >> >> > >>> >> >> >> >> > c) self class environment at: #Array >>> >> >> >> >> > => this will work in the future if your code is a class >>> which >>> >> >> >> >> > environment/namespace/module includes the Array class you >>> would >>> >> >> >> >> > expect >>> >> >> >> >> > >>> >> >> >> >> > a.1) #Array asClass >>> >> >> >> >> > b.2) Smalltalk at: #Array >>> >> >> >> >> > b.3) Smalltalk classNamed: #Array >>> >> >> >> >> > => In which namespace/module are you looking for #Array ? >>> In >>> >> >> >> >> > the >>> >> >> >> >> > future >>> >> >> >> >> > this >>> >> >> >> >> > may be removed, alternatively it will work only for >>> globals but >>> >> >> >> >> > not >>> >> >> >> >> > globals >>> >> >> >> >> > inside namespace/module which won't work since Array will >>> be in >>> >> >> >> >> > a >>> >> >> >> >> > module. >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > On Sat, Feb 10, 2018 at 12:57 PM, Peter UhnÃ¡k >>> >> >> >> >> > <i.uhnak(a)gmail.com> >>> >> >> >> >> > wrote: >>> >> >> >> >> >> >>> >> >> >> >> >> Hi, >>> >> >> >> >> >> >>> >> >> >> >> >> what is the canonical way to get a class from a symbol? >>> >> >> >> >> >> >>> >> >> >> >> >> a) Converting symbol into class via string protocol >>> >> >> >> >> >> >>> >> >> >> >> >> a.1) #Array asClass >>> >> >> >> >> >> I use this the most, because it is easy, uses unary >>> selector, >>> >> >> >> >> >> and >>> >> >> >> >> >> so >>> >> >> >> >> >> far >>> >> >> >> >> >> I've never ran into any issues. But apparently it is not >>> good >>> >> >> >> >> >> -- >>> >> >> >> >> >> why? >>> >> >> >> >> >> >>> >> >> >> >> >> a.2) #Array asClassInEnvironment: Smalltalk globals >>> >> >> >> >> >> >>> >> >> >> >> >> b) Retriving the class by key from the system dictionary >>> >> >> >> >> >> >>> >> >> >> >> >> b.1) Smalltalk globals at: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> b.2) Smalltalk at: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> b.3) Smalltalk classNamed: #Array >>> >> >> >> >> >> >>> >> >> >> >> >> c) something else entirely? >>> >> >> >> >> >> >>> >> >> >> >> >> I get that using #asClass wouldn't work if there was a >>> >> >> >> >> >> different >>> >> >> >> >> >> environment, however I don't even know in what situation >>> there >>> >> >> >> >> >> could >>> >> >> >> >> >> be >>> >> >> >> >> >> a >>> >> >> >> >> >> different environment, so I cannot assert how problematic >>> it >>> >> >> >> >> >> is >>> >> >> >> >> >> or >>> >> >> >> >> >> isn't. >>> >> >> >> >> >> >>> >> >> >> >> >> Thanks, >>> >> >> >> >> >> Peter >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > >>> >> >> >> >> > -- >>> >> >> >> >> > ClÃ©ment BÃ©ra >>> >> >> >> >> > Pharo consortium engineer >>> >> >> >> >> > https://clementbera.wordpress.com/ >>> >> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > ClÃ©ment BÃ©ra >>> >> >> >> > Pharo consortium engineer >>> >> >> >> > https://clementbera.wordpress.com/ >>> >> >> >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVillen…> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entr…> >>> >> >> >> >>> >> >> > >>> >> >> >>> >> > >>> >> >>> > >>> >>> >> > >

Feb. 13, 2018