[Vm-dev] Re: [Pharo-dev] Binding semantics of SystemDictionary
maxleske at gmail.com
Fri Apr 10 09:24:04 UTC 2015
> On 07 Apr 2015, at 13:30, vm-dev-request at lists.squeakfoundation.org wrote:
> 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
> 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.
I agree. I don’t like type checks. Just wanted to have talked about the option.
Thanks for your input Guille. I’m still not sure how to solve this issue for Fuel though. I see several options:
- signal an exception when the key to a global is not a symbol
- simply serialize a string representation of the key, which will lead to a lookup failure on materialization - > not good
- serialize the identityHash of the key. The identity hash of a symbol is stable across different images and VMs but not across Squeak and Pharo -> not good
- serialize the actual key. This requires us to rewrite the global handling logic and it will once again break backwards compatibility. This might be something for the future.
So maybe we should:
1. signal an exception -> no change for users
2. In a future version rewrite the global handling logic to allow for arbitrary global keys.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev