2018-02-10 11:33 GMT-03:00 Peter Uhnák <i.uh...@gmail.com>:
>> 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
