On 13 February 2018 at 17:25, Marcus Denker <marcus.den...@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 <dionisi...@gmail.com> > wrote: > >> >> >> 2018-02-11 21:08 GMT+01:00 Stephane Ducasse <stepharo.s...@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 <dionisi...@gmail.com> >>> wrote: >>> > >>> > >>> > 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand < >>> hernan.mora...@gmail.com>: >>> >> >>> >> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com>: >>> >> > Hi Hernan. >>> >> > >>> >> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand >>> >> > <hernan.mora...@gmail.com>: >>> >> >> >>> >> >> Hi Denis >>> >> >> >>> >> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisi...@gmail.com >>> >: >>> >> >> > >>> >> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse >>> >> >> > <stepharo.s...@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.clem...@gmail.com> >>> >> >> >> wrote: >>> >> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand >>> >> >> >> > <hernan.mora...@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.clem...@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.uh...@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&entry=gmail&source=g> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVilleneuve%2Bd%2527Ascq%26entry%3Dgmail%26source%3Dg%3E&entry=gmail&source=g> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entry=gmail&source=g> >>> >> >> >> >> >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > 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&entry=gmail&source=g> >>> ' >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d'Ascq+%3Chttps://maps.google.com/?q%3D40,%2Bavenue%2BHalley%2B59650%2BVilleneuve%2Bd%2527Ascq%26entry%3Dgmail%26source%3Dg%3E&entry=gmail&source=g> >>> Ascq >>> <https://maps.google.com/?q=40,+avenue+Halley+59650+Villeneuve+d%27Ascq&entry=gmail&source=g> >>> >> >> >> >>> >> >> > >>> >> >> >>> >> > >>> >> >>> > >>> >>> >> > >
