canonical way to convert Symbol into Class (retrieve class by its name)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

canonical way to convert Symbol into Class (retrieve class by its name)

Peter Uhnák
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
Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

jtuchel
Peter,

I have no answer for you as I am not a Pharo expert. It may be part of
an answer to your question "why?", however.

I think most if not all of the alternatives you mention are equally good
as long as you assume there is only one place to look for Classes.
As soon as you introduce namespaces to the equation, things get more
complicated. Depending on the logic of new implementations of these
lookup methods, the results may vary in such an environment.

just my 2 cents

Joachim


Am 10.02.18 um 12:57 schrieb Peter Uhnák:

> 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


--
-----------------------------------------------------------------------
Objektfabrik Joachim Tuchel          mailto:[hidden email]
Fliederweg 1                         http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1


Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Clément Bera-4
In reply to this post by Peter Uhnák
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 <[hidden email]> 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
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Peter Uhnák
> 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

Let's say that namespaces are added; Array is now in the module Collections.Array
My code is now in module MyProject.MyWhatever

I would imagine that in such situation I would need to change the code anyway, because it would try to look up MyProject.Array, no?

So if the argument for asClass is based on future addition of modules, then I will need to manually change it anyway regardless of what approach I used, because I don't know in which namespace the class will end up.

Am I missing something?

Thanks,
Peter


On Sat, Feb 10, 2018 at 1:47 PM, Clément Bera <[hidden email]> wrote:
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Clément Bera-4
Modules can import other modules to be able to use their classes directly.

Anyway, this is theory, there is no module implementation currently.

But the idea in the recent versions of Pharo (5-6-7) was to start moving away from things like (Smalltalk at: #className) or (#className asClass) since it does not work with the module system that is going to be introduced. 


On Sat, Feb 10, 2018 at 3:33 PM, Peter Uhnák <[hidden email]> wrote:
> 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

Let's say that namespaces are added; Array is now in the module Collections.Array
My code is now in module MyProject.MyWhatever

I would imagine that in such situation I would need to change the code anyway, because it would try to look up MyProject.Array, no?

So if the argument for asClass is based on future addition of modules, then I will need to manually change it anyway regardless of what approach I used, because I don't know in which namespace the class will end up.

Am I missing something?

Thanks,
Peter


On Sat, Feb 10, 2018 at 1:47 PM, Clément Bera <[hidden email]> wrote:
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 <[hidden email]> 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




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Esteban A. Maringolo
In reply to this post by Peter Uhnák
2018-02-10 11:33 GMT-03:00 Peter Uhnák <[hidden email]>:

>> 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
>
> Let's say that namespaces are added; Array is now in the module
> Collections.Array
> My code is now in module MyProject.MyWhatever
>
> I would imagine that in such situation I would need to change the code
> anyway, because it would try to look up MyProject.Array, no?
>
> So if the argument for asClass is based on future addition of modules, then
> I will need to manually change it anyway regardless of what approach I used,
> because I don't know in which namespace the class will end up.

If it is as in VisualWorks, it creates references, and such references
can be resolved dynamically.

If the reference specifies a namespace, then something such as
Core.OrderedCollection is resolved directly looking at the referenced
namespace, otherwise it looks at the same namespace of the class or
any namespace imported by the class definition.

With the added complexity of "nested" namespaces (Smalltalk.Core,
Smalltalk.Kernel, etc), and namespaces can also import other
namespaces, e.g.:
```
Smalltalk defineNameSpace: #Seaside
  private: false
  imports: '
    private Smalltalk.*
    private SUnit.*
    private Grease.*
  '
  category: ''
```

I think that the explicit namespacing approach adds more complexity
than anything else, I'd use a more dynamic approach, like using
modules.

Regards,


Esteban A. Maringolo

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

hernanmd
In reply to this post by Clément Bera-4
Hi Clément,

First time I read about modules in Pharo.
What is a module exactly?
What's the problem to solve?

Cheers,

Hernán

2018-02-10 9:47 GMT-03:00 Clément Bera <[hidden email]>:

> 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 <[hidden email]> 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'Ascq

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Clément Bera-4
On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand <[hidden email]> 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 <[hidden email]>:
> 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 <[hidden email]> 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'Ascq




--
Clément Béra
Pharo consortium engineer
Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Stephane Ducasse-3
Please to not use an unary on Symbol
Dispatch on something.

self class environment at: #Array
is the best

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 <[hidden email]> wrote:

> On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
> <[hidden email]> 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 <[hidden email]>:
>> > 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 <[hidden email]> 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'Ascq
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Denis Kudriashov

2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
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:

self class environment classNamed: #Array

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 <[hidden email]> wrote:
> On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
> <[hidden email]> 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 <[hidden email]>:
>> > 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 <[hidden email]> 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'Ascq
>>
>
>
>
> --
> Clément Béra
> Pharo consortium engineer
> https://clementbera.wordpress.com/
> Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq


Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Stephane Ducasse-3
Agreed!
In that case denis we should add a bug entry and clean the complete image.

And no asClass sucks and we do not want to use thisContext.
Why can we do simple thing and avoid to add more accidental complexity.

Stef

On Sat, Feb 10, 2018 at 7:18 PM, Denis Kudriashov <[hidden email]> wrote:

>
> 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
>>
>> 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:
>
> self class environment classNamed: #Array
>
>
> 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 <[hidden email]>
>> wrote:
>> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> > <[hidden email]> 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 <[hidden email]>:
>> >> > 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 <[hidden email]>
>> >> > 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'Ascq
>> >>
>> >
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

hernanmd
In reply to this post by Denis Kudriashov
Hi Denis

2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:

>
> 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
>>
>> 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?
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 <[hidden email]>
>> wrote:
>> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> > <[hidden email]> 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 <[hidden email]>:
>> >> > 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 <[hidden email]>
>> >> > 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'Ascq
>> >>
>> >
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Denis Kudriashov
Hi Hernan.

2018-02-11 19:57 GMT+01:00 Hernán Morales Durand <[hidden email]>:
Hi Denis

2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>
> 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
>>
>> 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 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 <[hidden email]>
>> wrote:
>> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> > <[hidden email]> 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 <[hidden email]>:
>> >> > 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 <[hidden email]>
>> >> > 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'Ascq
>> >>
>> >
>> >
>> >
>> > --
>> > Clément Béra
>> > Pharo consortium engineer
>> > https://clementbera.wordpress.com/
>> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

hernanmd
2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:

> Hi Hernan.
>
> 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> Hi Denis
>>
>> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >
>> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
>> >>
>> >> 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?

>>
>> 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 <[hidden email]>
>> >> wrote:
>> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> > 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 <[hidden email]>
>> >> >> > 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'Ascq
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Clément Béra
>> >> > Pharo consortium engineer
>> >> > https://clementbera.wordpress.com/
>> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >>
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Denis Kudriashov


2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
> Hi Hernan.
>
> 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> Hi Denis
>>
>> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >
>> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse <[hidden email]>:
>> >>
>> >> 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 <[hidden email]>
>> >> wrote:
>> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> > 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 <[hidden email]>
>> >> >> > 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'Ascq
>> >> >>
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Clément Béra
>> >> > Pharo consortium engineer
>> >> > https://clementbera.wordpress.com/
>> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >>
>> >
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Stephane Ducasse-3
Denis

we should introduce classNamed: now we can have traits and globals too :(
Idea? may be can still classNamed:

Stef


On Sun, Feb 11, 2018 at 8:55 PM, Denis Kudriashov <[hidden email]> wrote:

>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <[hidden email]>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <[hidden email]>:
>> >> >>
>> >> >> 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
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> >> > 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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'Ascq
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Clément Béra
>> >> >> > Pharo consortium engineer
>> >> >> > https://clementbera.wordpress.com/
>> >> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >> >>
>> >> >
>> >>
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

hernanmd
In reply to this post by Denis Kudriashov
2018-02-11 16:55 GMT-03:00 Denis Kudriashov <[hidden email]>:

>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <[hidden email]>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <[hidden email]>:
>> >> >>
>> >> >> 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.

Maybe it's too drastic not using any unary on Symbol. There are a lot
right now: #asIcon, #asMutator, #asSlot, #asString, #isDoIt, #senders,
etc. without counting those from String and up. I will check for the
past discussion.

>
> 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:
>

It's not a problem of like ir or not.
It's about future migration effort for issues which maybe are not so common.

> 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).
>

Ok, thanks for the clarification.

Cheers,

Hernán

>>
>>
>> >>
>> >> 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
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> >> > 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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'Ascq
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Clément Béra
>> >> >> > Pharo consortium engineer
>> >> >> > https://clementbera.wordpress.com/
>> >> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >> >>
>> >> >
>> >>
>> >
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Denis Kudriashov
In reply to this post by Stephane Ducasse-3


2018-02-11 21:08 GMT+01:00 Stephane Ducasse <[hidden email]>:
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 <[hidden email]> wrote:
>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <[hidden email]>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <[hidden email]>:
>> >> >>
>> >> >> 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
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> >> > 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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'Ascq
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Clément Béra
>> >> >> > Pharo consortium engineer
>> >> >> > https://clementbera.wordpress.com/
>> >> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >> >>
>> >> >
>> >>
>> >
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Richard Sargent
Administrator
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 <[hidden email]> wrote:


2018-02-11 21:08 GMT+01:00 Stephane Ducasse <[hidden email]>:
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 <[hidden email]> wrote:
>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <[hidden email]>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <[hidden email]>:
>> >> >>
>> >> >> 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
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> >> > 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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'Ascq
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Clément Béra
>> >> >> > Pharo consortium engineer
>> >> >> > https://clementbera.wordpress.com/
>> >> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >> >>
>> >> >
>> >>
>> >
>>
>



Reply | Threaded
Open this post in threaded view
|

Re: canonical way to convert Symbol into Class (retrieve class by its name)

Marcus Denker-4
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: [  ].

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 <[hidden email]> 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 <[hidden email]> wrote:


2018-02-11 21:08 GMT+01:00 Stephane Ducasse <[hidden email]>:
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 <[hidden email]> wrote:
>
>
> 2018-02-11 20:36 GMT+01:00 Hernán Morales Durand <[hidden email]>:
>>
>> 2018-02-11 16:10 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> > Hi Hernan.
>> >
>> > 2018-02-11 19:57 GMT+01:00 Hernán Morales Durand
>> > <[hidden email]>:
>> >>
>> >> Hi Denis
>> >>
>> >> 2018-02-10 15:18 GMT-03:00 Denis Kudriashov <[hidden email]>:
>> >> >
>> >> > 2018-02-10 20:59 GMT+03:00 Stephane Ducasse
>> >> > <[hidden email]>:
>> >> >>
>> >> >> 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
>> >> >> <[hidden email]>
>> >> >> wrote:
>> >> >> > On Sat, Feb 10, 2018 at 4:34 PM, Hernán Morales Durand
>> >> >> > <[hidden email]> 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 <[hidden email]>:
>> >> >> >> > 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
>> >> >> >> > <[hidden email]>
>> >> >> >> > 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'Ascq
>> >> >> >>
>> >> >> >
>> >> >> >
>> >> >> >
>> >> >> > --
>> >> >> > Clément Béra
>> >> >> > Pharo consortium engineer
>> >> >> > https://clementbera.wordpress.com/
>> >> >> > Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
>> >> >>
>> >> >
>> >>
>> >
>>
>




12