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

[Guillermo Polito]

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 at gmail.com> escribió:

> 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
> 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20150410/b17e98b2/attachment.htm