On 11 Feb 2018, at 22:12, Richard Sargent
<richard.sarg...@gemtalksystems.com
<mailto:richard.sarg...@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 <mailto:dionisi...@gmail.com>> wrote:
2018-02-11 21:08 GMT+01:00 Stephane Ducasse
<stepharo.s...@gmail.com <mailto: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 <mailto:dionisi...@gmail.com>> wrote:
>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand
<hernan.mora...@gmail.com <mailto:hernan.mora...@gmail.com>>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov
<dionisi...@gmail.com <mailto:dionisi...@gmail.com>>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <hernan.mora...@gmail.com
<mailto:hernan.mora...@gmail.com>>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov
<dionisi...@gmail.com <mailto:dionisi...@gmail.com>>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <stepharo.s...@gmail.com
<mailto: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
<mailto:bera.clem...@gmail.com>>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales
Durand
>> >> >> > <hernan.mora...@gmail.com
<mailto: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 <mailto: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 <mailto: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/
<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/
<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>
>> >> >>
>> >> >
>> >>
>> >
>>
>
