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

[Martin Dias]

On Sun, Apr 12, 2015 at 12:41 PM, Max Leske <maxleske at gmail.com> wrote:

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

+1

I agree with signaling an error, if there are no real cases. However, I
don't defend the "all class names are byte strings" assumption of Fuel. Of
course, it could be optimized for such cases, but it should also support
other objects...

Martín


> Cheers,
> Max
>
>
> 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/20150413/33969450/attachment-0001.htm