Hmm, there is something that I'm missing: do you have a real case where fuel is failing? :) if so, I'd focus on that: where does it come from, how was that class created, maybe it's a very specific case that you can handle in an ad-hoc way (and then leave fuel as it is right now...) El vie., 10 de abr. de 2015 a la(s) 11:24 a. m., Max Leske < maxleske@gmail.com> escribió:
On 07 Apr 2015, at 13:30, vm-dev-request@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 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.
Interesting.
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.
Opinions?
Cheers, Max _______________________________________________ Pharo-fuel mailing list Pharo-fuel@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel