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

Max Leske maxleske at gmail.com
Sun Apr 12 10:41:05 UTC 2015


> On 10 Apr 2015, at 11:28, Guillermo Polito <guillermopolito at gmail.com> wrote:
> 
> Hmm, there is something that I'm missing:
> 
> do you have a real case where fuel is failing? :)

No :) But it’s something that has the potential to fail at any time.

> 
> 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…)

That’s why I suggested signalling an exception. It wouldn’t change anything about Fuel. But in case someone encounters the problem, Fuel will fail early (during serialization) instead of (very) late (during materialization).

Cheers,
Max

> 
> El vie., 10 de abr. de 2015 a la(s) 11:24 a. m., Max Leske <maxleske at gmail.com <mailto:maxleske at gmail.com>> escribió:
>> On 07 Apr 2015, at 13:30, vm-dev-request at lists.squeakfoundation.org <mailto: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 <mailto:Pharo-fuel at lists.gforge.inria.fr>
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel <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/20150412/8cacedd9/attachment.htm


More information about the Vm-dev mailing list