[Vm-dev] Re: [Pharo-dev] Binding semantics of SystemDictionary

Guillermo Polito guillermopolito at gmail.com
Tue Apr 7 11:30:03 UTC 2015


Hmm, I think we are mixing stuff here ^^

Method Dictionaries and system dictionary accept any object as keys.

To execute code, the VM only checks for identity (+ identity hash that does
not change) in method dictionaries. The VM never looks up in the system
dictionary.
Actually the VM does not make any assumption on the objects you put as
keys. This makes the VM simpler.
Then tools enforce that we put there symbols as keys in both. But, we could
put anything we would like.

So, answering your questions:

1. Are bindings with keys that are not ByteString or ByteSymbol valid?

    Theoretically yes, but nobody uses this for real for now. Camille has
some prototypes that uses this to enforce modularity.

2. Should we keep allowing ByteString as keys to globals (ByteSymbol
guarantees identity)?

    Well, usually the tools will make sure that you transform them to a
symbol before.

3. If we allow ByteString, do we also allow WideString?

    Any object ^^

4. Would “type checks” on SystemDictionary incur a big performance penalty?

   Maybe, but not only that. It makes the code more messy also, and
hardcode tool assumptions. I don't put any type checks in any of my code
usually, why start there... We should fix fuel to not make that assumption
instead I think.

El dom., 5 de abr. de 2015 a la(s) 8:40 p. m., Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com> escribió:

> 2015-04-04 14:55 GMT+02:00 Max Leske <maxleske at gmail.com>:
>
>>
>>
>> On 31 Mar 2015, at 23:12, Nicolas Cellier <
>> nicolas.cellier.aka.nice at gmail.com> wrote:
>>
>>
>> Thanks Nicolas. I was hoping to see a bit more activity on this thread so
>> I didn’t reply immediately.
>>
>> 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.
>>
>
> Nope, no problem, I think we just use the identityHash, so nowhere a
> symbol is required.
> It's only a problem at higher level, image-side, for IDE.
>
>
>>
>> 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 at 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
>>>
>>
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150407/0c10a788/attachment-0001.htm


More information about the Vm-dev mailing list