View Issue Details

IDProjectCategoryView StatusLast Update
0000696LDMud 3.7Compilation, Installationpublic2022-10-06 19:59
Reporterzesstra Assigned To 
Status newResolutionopen 
Summary0000696: Change some efuns to return structs
DescriptionLDMud recently gained the capability to return structs from efuns.

We now need to define which efuns should be changed in 3.7.x.
Ideas: driver_info (DI_TRACE), ...?

--- historic/obsolete description ---
 thought today of efuns returning structs.
Usually we return arrays, if efuns return more than one value. But struct are nice as well (nearly as fast, but typed). I could imagine it for efuns like object_info(), driver_info(), query_limits(), call_out_info() and such...

As far as I can see: returning structs is not a big problem (now that they are not optional anymore), but returning anonymous structs is not better than arrays. So, we would the type definitions for these structs independent of a specific program being loaded...

Some ideas: kind of simul_efun for structs? Or struct-preloads? Then we would have to supply the right struct types in LPC (write them on-the-fly?) or have them implicitly defined and 'inherited' by any program...
TagsNo tags attached.


related to 0000897 resolvedGnomi LDMud 3.6 Support global struct definitions via simul_efun object 



2009-11-01 04:35

reporter   ~0001576

I am using the 'inherit the struct definition' in multiple programs a lot. Frankly, this is just messy. With complex inheritance trees you will easily end up inheriting the same object (the file defining the struct) many times. It's just overkill.
Then there is the question of changing the struct definition at runtime. With multiple inheritance and only partly reloading the inheritance tree, you may end up - by accident, but this happens a lot - with programs that should exchange struct-data, but are unable to do so, because one part expects variation A and another expects variation B of a struct. Never destroy an inherit with struct definitions!

Maybe a way out of here would be to make struct definitions global. Their namespaces already are.


2009-11-01 15:06

administrator   ~0001578

This reloading/changing of structs in complex inherit trees seems to me the biggest obstacle as well and one reason why we don't share structs between programs at all until now.

If we introduce global structs, I would appreciate very much, if there could be global and program-bound structs...
But even then we still have the basic problem of changing/reloading structs: Suppose you have a global struct callout_s which is used by a lot of programs (which may be also often cloned). If you now reload the global callout_s and the compiler does not happen to merge the old and new struct, we have a new one. Now all existing programs must use the old struct definition and all newly loaded programs use the new one and we have the same issue...


2021-04-16 23:36

administrator   ~0002609

We are still interested in this, but do not yet have a very nice idea how to implement it. But it is anyway a breaking change and we post-pone it to 3.7.


2022-10-06 19:59

manager   ~0002685

A candidate would be get_dir() returning arrays of structs.

Issue History

Date Modified Username Field Change
2009-10-27 16:26 zesstra New Issue
2009-10-27 16:37 zesstra Description Updated
2009-11-01 04:35 _xtian_ Note Added: 0001576
2009-11-01 15:06 zesstra Note Added: 0001578
2021-04-16 23:36 zesstra Note Added: 0002609
2021-04-16 23:36 zesstra Project LDMud 3.5 => LDMud 3.7
2021-04-16 23:36 zesstra Category Efuns => General
2021-10-06 00:24 Gnomi Relationship added related to 0000897
2022-10-06 19:55 zesstra Category General => Compilation, Installation
2022-10-06 19:55 zesstra Description Updated
2022-10-06 19:55 zesstra Summary structs as return values of efuns => Change some efuns to return structs
2022-10-06 19:59 Gnomi Note Added: 0002685