libera/#commonlisp - IRC Chatlog
Search
18:52:56
alcor
_death: It does something to the effect of replacing every instance pointer to X in the image with a pointer to instance Y, thus allowing one to transparently implement the decorator pattern i.e. turning an anemic object to a non-anemic one
18:54:44
_death
alcor: I see.. the post by Gilad Bracha says "In the absence of an object table, become: traverses the heap in a manner similar to a garbage collector." ...
18:55:32
semz
mi6x3m: fwiw that op is underspecified, unless you specifically want the fractional part to be hundredths. Is (foo 1 1) 1.1? 1.01? 1.001? etc
18:56:05
fiddlerwoaroof
I think the idea is that the fractional part is divided by 10 raised to its length
18:57:35
gilberth
I believe the ideas was that this FOO gets strings. Perhaps gathered while parsing something.
18:57:49
alcor
_death: Yes, I'm not sure how modern Smalltalk implements it efficiently. It sounds computationally expensive, but powerful (where applicable). Haven't heard of any other platform that can do that.
18:58:28
fiddlerwoaroof
There's probably some sort of inline cache strategy that could handle this relatively efficiently
19:02:04
_death
alcor: what I'm wondering is how useful would that be, if you already have a change-class operator (that doesn't need to change references, in practice using the indirection approach)
19:08:50
alcor
_death: change-class just changes the class, it doesn't touch the state (or rather, it delegates that to update-instance-for-different-class)
19:09:19
alcor
_death: "change-all-references" has at least simpler semantics. It does what it says.
19:09:31
_death
alcor: what you maybe meaning to say is that it may touch the state (via u-i-f-d-c) but not identity
19:11:27
alcor
_death: Kind of. State handling with change-class harbors a few footguns that don't exist with the nuclear approach that is reference patching
19:17:10
alcor
_death: To quote the CLHS: "If in the old class there is any slot of the same name as a local slot in the new-class, the value of that slot is retained"
19:20:00
_death
that just sounds like part of the protocol.. granted if a programmer didn't expect it to happen, may have footache, but doesn't that mean that anything can serve as a footgun?
19:26:03
alcor
It makes naming collisions hurt, but admittedly I don't know how a better solution could look like (perhaps raising a condition?)
19:27:47
alcor
The issue is that it's subtle and causes no explicit error. It's one of these things that can create difficult-to-debug issues.
19:27:58
_death
but I agree that change-class (that requires an instance evolution protocol) is more elaborate
20:30:22
pve
I was wondering the other day if "become:" can be simulated in CL somehow, but it probably can't, right?