The miracle of Smalltalk’s become: (2009)

https://gbracha.blogspot.com/2009/07/miracle-of-become.html

by nathell • 4 years ago

89 29 4 years ago

gbracha.blogspot.com

atemerev• 4 years ago

"become" is a standard approach in Erlang, Akka and other actor model systems (because it is included in the original actor model axioms by Carl Hewitt, "[a message can] designate the behavior to be used for the next message it receives"). We write state machines with that (on some events, you just 'become' another state with its own reactions to messages).

masklinn2• 4 years ago

It helps a lot that there's limited way to inspect an actor in a way which is not mediated by the actor itself, so for starters you wouldn't bother, and even if you did the "replacement" actor can just reply in a way you'd expected.

yccs272• 4 years ago

This would've been very convenient for lazy loading in a recent python project. I ended up making the husk turn into a transparent wrapper for the loaded object, unfortunately adding a layer of indirection to every subsequent call. Does anyone here know a better way to do lazy loading objects in python?

masklinn2• 4 years ago

If all the types are the same shape (at the C level) you can swap the class and all attributes of the husk.

BiteCode_dev2• 4 years ago

Use ChainMap in __dict__

yccs272• 4 years ago

That works? Wow, I need to try this.

andai• 4 years ago

    Object.prototype.become = function(target) {
        
        const newProto = Object.getPrototypeOf(target);
        Object.setPrototypeOf(this, newProto);
        
        for ( let key of Object.keys(this) ) {
            delete this[key];
        }

        Object.assign(this, target);

    }

Here's as close as I could get in JS. This fails Object.is(a,b) though, it just makes object A's data the same as B's.

The two objects will desynchronize, unless all their properties are Objects (eg. Arrays) and no new ones are added.

As far as I know there's no way to update all references to an object to point to a new object. Though you could take the article's advice and add a bunch of indirection with getters and setters, referencing an internal "true" object which could be swapped out trivially.

cxr• 4 years ago

Getters and setters will also desynchronize for similar reasons (new properties being added/removed).

In JS you're better served by proxies or to set things up ahead of time so you're not passing a direct object reference, but a mirror instead.

<https://bracha.org/mirrors.pdf>

Once you've got all relevant consumers using a mirror or a proxy and all access is therefore mediated, that's when you can freely perform these kind of swaps.

As noted by the commenters, however, this is quite a heavyweight solution.

Inside the engine, a clever trick from Smalltalk called `becomes` is used to swap a newborn Proxy and an existing object that has arbitrarily many live references. Thus an object requiring no behavioral intercession can avoid the overhead of traps until it escapes from a same-origin or same-thread context, and only if it does escape through a barrier will it become a trapping Proxy whose handler accesses the original object after performing access control checks or mutual exclusion.
The local jargon for such object/Proxy swapping is “brain transplants”.

<https://brendaneich.com/2010/11/proxy-inception/>

<https://bugzilla.mozilla.org/show_bug.cgi?id=580128>

heisenbit• 4 years ago

Combining ‚become:‘ with the ability to serialize objects was fun.

zulu-inuoe• 4 years ago

Closest equivalent that I can think of is the change-class function in CL. That one also happens to be generic so you can control the finer details of what it means to change A to B

karmakaze• 4 years ago

Take a minute to internalize this; you might misunderstand it as something trivial. This is not about swapping two variables - it is literally about one object becoming another. I am not aware of any other language that has this feature. It is a feature of enormous power - and danger.

I do think implementing or understanding this is trivial. 'Become' can be implemented by 1. swapping all references to 'a' and 'b', or 2. swapping the data at memory locations of 'a' and 'b'. I can certainly see its interesting uses but don't see any value in describing it as a miracle or something that's hard to comprehend. Using the word 'become' to explain the language feature 'become' also isn't great.

I used ObjectStore at one company that does 'pointer swizzling' to lazy load deserialized objects, where segfault takes the place of `doesNotUnderstand`.

pjmlp4• 4 years ago

I usually use it as an example when people say Python is too dynamic to have a JIT, when Smalltalk was one of the percusors of JIT for dynamic languages with features like become: (SELF then took it even further).

taeric2• 4 years ago

If I'm not mistaken, this is also an amusing retort to the idea that only statically typed languages can have common refactoring tools.

Qem• 4 years ago

It's really unnerving when people repeat that "too dynamic" remark when there is widely known counterexamples. Fortunately it seems now people stopped denying the problem with the faster cpython project. IIRC, I think the roadmap for 3.12 or 3.13 already has some form of lightweight JIT.

dingosity2• 4 years ago

The magic here comes from Smalltalk's object memory system, which makes this object easy. (Well.. okay.. not completely easy, but simple.)

Also... I know in Digitalk, you couldn't do a become: on SmallInteger because of the way their object memory worked, but don't remember if this was a limitation of SmallTalk-80 or Squeak.

Which is to say... when you have time, if you haven't done it already, do a search on "smalltalk object memory" or "Loom" or "bluebook object memory." There are some great references from the dawn of time.

thecodedmessage• 4 years ago

Squeak implements it with horrible performance, IIRC

dingosity2• 4 years ago

I hear you. The last time I used squeak as a prototyping tool was around 2002 and yeah, the performance was pretty craptastic. I bumped into David Ungar at a conference a few years back. He mentioned there has been a fair amount of work back-ported to Squeak from some of the later Self work and maybe even from Lively Kernel for all I know.

But lest someone read this thread and use it as evidence that Squeak is completely crappy, I would encourage them to do a bit of testing with a recent version. Also... I don't think people are going to use Smalltalk for it's raw performance, but in it's ability to model problems with pleasant "pure" OOP-ness.

Samis20012• 4 years ago

The SmallInteger limitation is probably because as an optimisation they stored them as immediate values rather than generic objects, and Squeak shares this limitation (the newer Spur format extends this to one or more additional types depending on image bitness).

Related to references and the above, Eliot Miranda's blog may be informative as it provides both details and sometimes code for many of the changes that have happened in the Squeak (and now OpenSmalltalk) VM, e.g. http://www.mirandabanda.org/cogblog/2013/09/13/lazy-become-a...

c-smile2• 4 years ago

In fact in most cases dynamic subclassing is enough for such things. In JavaScript that's achieved by changing __proto__ reference on an object.

So "obj instanceof A" becomes "obj instanceof B".

As of persistence case I've solved it on JavaScript internal implementation level. In Sciter there is built-in JSON-ish data persistence module - close to Mongo-DB on feature set (modulo sharding).

Storage loads objects as half-backed proxies that contain only db references. Only when code tries to access props/methods of the loaded object it gets fetched from disk, its __proto__ is set to particular class, etc.

More on this architecture: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d...

By the way, dynamic subclassing is not a prerogative of only dynamic languages, here is how I did that in C++: https://stackoverflow.com/questions/21212379/changing-vtbl-o...

Patched QuickJS with storage support is here: https://gitlab.com/c-smile/quickjspp - it uses DyBase of Konstantin Knizhnik as a storage.

kazinator2• 4 years ago

Not really, because the goal is that obj is replaced by a different instance, not to change its type.

Become can swap two objects that are exactly of the same type, where the prototype change would be a null operation, achieving nothing.

c-smile2• 4 years ago

"obj is replaced by a different instance"

Could you provide real life scenario when you will need that?

I mean to change all references to the object in the heap at runtime ...

AustinDev• 4 years ago

True become false

kazinator2• 4 years ago

In the absence of an object table, become: traverses the heap in a manner similar to a garbage collector. The more memory you have, the more expensive become: becomes.

Well, yes, that should be "the larger the reachable object graph you have, the more expensive become: becomes". It's not necessary to do the substitution in areas of the heap that are garbage.

I would rather do it without any sort of object table, because then you can do things like make some string object become the fixnum 42 everywhere. :)

If you're doing something with object persistence, you can't be doing individual become operations object-by-object. There has to be a batch API for doing a mass become where you pass a dictionary of what is to become what, and the objects are traversed once to do all the rewrites.

The miracle of Smalltalk’s become: (2009)

Related Stories