��

On 10 Apr 2015, at 11:28, Guillermo Polito <guillermopolito@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@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