2018-02-13 10:25 GMT+01:00 Marcus Denker <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.
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@ 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@gmail.com> wrote:
2018-02-11 21:08 GMT+01:00 Stephane Ducasse <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@gmail.com> wrote:
2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <
hernan.morales@gmail.com>:
2018-02-11 16:10 GMT-03:00 Denis Kudriashov <dionisiydk@gmail.com>:
Hi Hernan.
2018-02-11 19:57 GMT+01:00 Hernán Morales Durand <hernan.morales@gmail.com>:
Hi Denis
2018-02-10 15:18 GMT-03:00 Denis Kudriashov <dionisiydk@gmail.com
:
2018-02-10 20:59 GMT+03:00 Stephane Ducasse <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@gmail.com> wrote:
On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand <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@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@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...> ' <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...>
-- 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...> ' <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...>