not only the globals but the methods in MethodDictionary too :)

Ok, that might even be worse. AFAIK MethodDictionary is treated as a special class by the VM. So storing other objects in there may be a real problem, not just a philosphical one. CC��ing vm-dev on this.

It might be a feature, it's just that it's unused because of limited IDE and compiler.

If you look far enough, almost anything can be considered a feature�� :)

2015-03-31 20:49 GMT+02:00 Max Leske <maxleske@gmail.com>:
Hi

Tommaso and I, while hacking on Fuel, today discovered that globals in Pharo can have very weird bindings (I guess some of you already know that). For example:

class := Class new
setName: 4;
yourself.
Smalltalk
at: class name
put: class.

So we now have a class with name 4 (which is a SmallInteger):

self assert: (Smalltalk at: 4) == class.

There are basically two different issues:
1. SystemDictionary will store any kind of association, not only symbols / strings
2. SystemDictionary is an IdentityDictionary and as such two equivalent but not identical keys will not resolve to the same object:

class := Class new
setName: (String streamContents: [ :s | s nextPutAll: 'someName']);
yourself.
Smalltalk
at: class name
put: class.

Smalltalk
at: (String streamContents: [ :s | s nextPutAll: 'someName��])
ifAbsent: [ false ]. ��> false��

In Fuel we simply assume that any key to a global is either a ByteString or ByteSymbol. If that��s not the case bad things happen.
It would help us a lot if we could clear up the semantics of bindings in SystemDictionary:
1. Are bindings with keys that are not ByteString or ByteSymbol valid?
2. Should we keep allowing ByteString as keys to globals (ByteSymbol guarantees identity)?
3. If we allow ByteString, do we also allow WideString?
4. Would ��type checks�� on SystemDictionary incur a big performance penalty?

Any suggestions are welcome.

Cheers,
Max