View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000682 | LDMud | Implementation | public | 2009-09-26 16:45 | 2009-10-05 07:33 |
| Reporter | zesstra | Assigned To | |||
| Priority | low | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000682: Auto-destructed / Auto-cleaned objects | ||||
| Description | This idea is in my mind for quite some time now and I think, I should it record in finally here: A flag for an object which tells the driver to automatically destruct the object shortly after there is no (external) reference to that object. This is especially related to the idea of 'light-weight' objects (nameless objects). But there may be even a usage for normal clones. Imagine the situation a wizard clones and object and does not move it in some environment, because the move into the player/room/container fails and he doesn't check for that. In that case, the clone will leak and in practice just fill up memory (in former times, MG had hundred-thhousands of such leaked objects but since a number of years, clones of standard items (thing, weapon, armour, everything which should have player interaction) raise an error and self-destruct if they are without environment 2s after creation. (Short digression to light-weight objects: They would have much less overhead in creation and function calls (call_other) than normal objects and could be used to implement structures like ring buffers efficiently, which is now not possible. An idea here would be to bind functions to data structures (e.g. mappings/structs), but there are only a preliminary and rough ideas about such light-weight objects.) | ||||
| Tags | No tags attached. | ||||
| External Data (URL) | |||||
|
|
In my mind, this is what structs should be used for, i.e. implementing complex data structures in a way you would do with C (not C++). Something like: get_next_ring_buffer( struct ring_buffer_t ) Of course this doesn't offer the features of OOP, but it is feasible atm. Note: This has some problems: Ex: Ring buffers leak memory due to the circular self-reference in the list. Also: In our lib we handle the case of catching moves that went wrong and didnt move the object at all with a call_out(, 0). |
|
|
We also check objects without environment, although this is not the most elegant way. Using structs for ringbuffers is fine, I had such an implementation for playing around. But something like object buf=clone("/std/ring_buffer"), buf->add(foo); would be interesting, if you could spare the huge overhead it currently has. That would suggest a very tight binding between code/behaviour and data of the entity. I think, there was once the idea of binding closures to structures which might be executed/called by struct->fun(). BTW: the strategy of inheriting a ringbuffer struct and lfuns manipulating it: in my experience, the function call overhead was so large, that it was faster to perform a arr = ({foo}) + arr[1..]; for every addition than to actually call something like RingBufferPut(buf, foo); I then abandoned the project (although the code still lies around somewhere). |
