[Vm-dev] [squeak-dev] Object new becomeForward: #normal
eliot.miranda at gmail.com
Thu Jul 20 21:34:49 UTC 2017
On Thu, Jul 20, 2017 at 2:26 PM, Chris Muller <asqueaker at gmail.com> wrote:
> >>> The former is technically impossible due to different object
> >>> representations, the latter is possible and not restricted at all. For
> >>> example, true and false are not immediate objects, you can use
> #become*: on
> >>> them to blow your image up.
> >>> So, there's no restriction at all if it's technically possible to use
> >>> #become*:.
> >>> The responsibility model is the simplest here: use at your own risk.
> >>> Since this comes up every once in a while, I suggest a comment be added
> >>> to those methods stating the responsibility model explicitly.
> >> +1
> Why express +1 for the responsibility model for use of become: (which
> I agree with), but not for mutating objects?
> >> *Especially* a warning that becomeForward: does modify the target's
> I assume this is not referring to a Warning signal here, but just
> something in the comment. But even that wouldn't be necessary as long
> as the indirection remains, since the "copyHash: false" code makes
> that very clear.
> >>> I don't know how the VM handles immutability in this case, but it's
> >>> possible that it wouldn't let #become*: affect immutable objects.
> >> I think that would be fine, you should be able to become an immutable
> >> object and vice versa.
> >>> On the other hand, I'm sure it would let you change fields of immutable
> >>> objects via #become*:, but that's not an issue in your case.
> >> This is debatable ... I would rather have the VM raise an error when
> >> trying to become a field of an immutable object. Immutable should mean
> >> immutable, no?
> So for bulkBecome:, will the error mean it becomed some of them (the
> ones that that could), but not all? It's getting complex!
None of them. The semantics of primitives should be they either succeed
and answer their result, or they fail without side-effects. Alas the
ImageSegment loading primitive is an exception, but I believe it's the only
one. So in the become primitives, validation is done before any becomes,
including computing an estimate of any memory needed, and the entire bulk
become will fail if any single object fails validation and/or if there is
not enough memory to complete the operation (two-way become may involve
creating copies of objects).
> > However, it seems to me that becomerForward: doing a copyHash is itself a
> > bug. What's the rationale for copying the receiver's hash to the target
> > object?
> For when you become a Proxy object to a Symbol selector to perform,
> which are keys in MethodDictionary's. It's absolutely essential.
This doesn't make sense to me. Are you saying one has a proxy for a Symbol
that is not present, this gets entered as a key into MethodDictionaries,
and later is becalmed into the Symbol it represents? If not, can you take
me through the use-case?
It seems to me that what one wants is the ability to determine an Object's
identityHash. I've long thought that Symbols should set their identityHash
on creation so that Symbols identityHashes are constant across all
systems. This would men for example, that binary code loaders would not
need to rehash method dictionaries because they would already be correctly
hashed. In these cases one definitely doesn't want to overwrite the
target's identityHash; instead, taking your example, one would want to
create the proxy with the identityHash of its target.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev