View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000696 | LDMud 3.7 | Compilation, Installation | public | 2009-10-27 15:26 | 2022-10-06 17:59 |
| Reporter | zesstra | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | open | ||
| Summary | 0000696: Change some efuns to return structs | ||||
| Description | LDMud 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... | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
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... |
|
|
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. |
|
|
A candidate would be get_dir() returning arrays of structs. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2009-10-27 15:26 | zesstra | New Issue | |
| 2009-10-27 15:37 | zesstra | Description Updated | |
| 2009-11-01 03:35 | _xtian_ | Note Added: 0001576 | |
| 2009-11-01 14:06 | zesstra | Note Added: 0001578 | |
| 2021-04-16 21:36 | zesstra | Note Added: 0002609 | |
| 2021-04-16 21:36 | zesstra | Project | LDMud 3.5 => LDMud 3.7 |
| 2021-04-16 21:36 | zesstra | Category | Efuns => General |
| 2021-10-05 22:24 | Gnomi | Relationship added | related to 0000897 |
| 2022-10-06 17:55 | zesstra | Category | General => Compilation, Installation |
| 2022-10-06 17:55 | zesstra | Description Updated | |
| 2022-10-06 17:55 | zesstra | Summary | structs as return values of efuns => Change some efuns to return structs |
| 2022-10-06 17:59 | Gnomi | Note Added: 0002685 |
