A way to clear a datum's changed vars list

ID:2094108
 
Jun 3 2016, 9:00 pm
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
Had an idea, in a few places we while loop thru a things vars array and reset their vars, and i got to thinking, wait a minute, this could be as simple as clearing the thing's changed vars. (would still require a loop, to lower ref counters, but it would be an o(n) loop, not an o(n ^ (n log n)) loop, and be outside of game code so thus faster, and also actually reset memory usage)

I tried thing.vars = initial(thing.vars) but that didn't work. (modify const compile error)

I suppose you could make that initial trick work if you didn't want to create a new proc for doing this, but that sounds like it might be much harder to code and add more snowflake checks to compile code.

This would make generic code to pool often created and deleted things much more efficient (as well as a couple other places)

Jun 3 2016, 9:14 pm
Pleeeease add this. This is my current workaround and it's janky as f.

var/list/constVars = list("locs", "type", "parent_type", "verbs", "vars")
obj
    proc
        deinitialize()
            if(updater)removeUpdater(src)
            for(var/v in vars)
                if(v in constVars)continue
                if(istype(vars[v],/list))
                    vars[v] = new/list()
                else
                    vars[v] = initial(vars[v])


This also seems to not play nice with the matrix vars sometimes.
Jun 3 2016, 10:21 pm
Hmm. That's an interesting notion. This would have to take several forms:

1) Delete any attached soft vars. (This is the easy part.)
2) Restore the appearance, if applicable, to the default for that object type.
3) Restore non-appearance vars (and pixel offsets for movables) to the default for that object type.
4) Redo the init proc, if any.

Although, maybe it makes way more sense to simply clear out the object and re-New() it, without actually calling New() or ever deleting it.
Jun 4 2016, 1:52 am
Sounds like a job for args and/or flags.

I could see some people wanting it to re-New() and re-init, I could see some not caring about appearance vars, hell i could see some uses that only care about user defined vars and not builtins. Some might want a re-init, but not a re-New(). The idea is to help lower overhead of dealing with temp objects, so control over what overhead even takes place is ideal.

The usage that got me thinking about this is our GC subsystem, for when it detects something not soft deleting/GCing, it could clear its vars and then wait a bit more before it actually hard del()s it (with the idea that 90% of the time, the thing stopping GCing is circular references with other things that were queued for deletion, so it would allow a GC in those cases without a costly del()).

So in that case, I wouldn't care about actually reusing the object, i just want to help it along to garbage collection and have it not stop other things from garbage collecting that are also in the queue of deleted things to be checked, its extremely unlikely that a builtin var could be stopping it, as those are already reset properly in the parent Destroy() proc for the type that adds the builtin.

The other case is our pooling system, that one would want all vars reset, but wouldn't want to init until later, and we already handle doing that when the object leaves the pool.

I suppose two args would do the trick: proc/WhatEverName(inittype = INIT_NONE=0|INIT_VARS=1|INIT_VARS_AND_NEW=2, cleartype = CLEAR_USER=1,CLEAR_BUILTINS=2,CLEAR_APPEARANCE=4)

with init_type being a level (not a bitflag) and cleartype being a bitflag.

(just a note, init_vars_and_new would be unlikely to be used at /tg/, but i could see some games finding it useful, even if you don't, they can just re-New() anyways. INIT_VARS could be useful, but we are already trying to move away from them for reasons you already know.)