View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000734 | LDMud 3.7 | LPC Language | public | 2010-03-10 17:49 | 2021-04-17 10:34 |
| Reporter | _xtian_ | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | acknowledged | Resolution | open | ||
| Summary | 0000734: warn_nomask modifier | ||||
| Description | And another modifier idea: I find myself adding "nomask" modifiers a lot to old code. It is a great way to ensure that inheriters don't break some API functionality or build hacks on assumptions that change over time. Mostly I do this in several steps, where I first announce my intention to add "nomask" to a core function (this usually is shamelessly ignored), then I start grepping for all users of that function. Unfortunately I nearly always miss some of those, so when I finally make the function "nomask", some code ends up not compiling any more. It would be nice to be able to add another step, where I add a "warn_nomask" modifier, which only throws a warning instead of an error. So we could find masking functions earlier. | ||||
| Tags | No tags attached. | ||||
| related to | 0000735 | closed | LDMud | pragma warn_only |
|
|
Hehe, I know the problem, that nobody cares about announcements like this. ;-) (Although using nomask to fix the interface is a quite drastic step. But I can feel with you, I encountered too much crap which people redefined mudlib functionality with, sometimes they copied the mudlib lfun, appended a single line and now the behaviour is drastically different to the rest of the mud.) Well, one first comment: after the 'deprecated' flag we don't have a free bit in the function flags left. ;-) So first we have to change the function flags to a 64 bit type and check code for hard-coded assumptions about its size. The bright side is, that we anyway plan to move the function headers from the bytecode into a separate table in the program structure. |
|
|
modifier flags field: What I tried a few years back - and obviously I didn't finish that or send it in - was to seperate the field for function flags and variable flags. If I remember correctly enough Defines don't overlap, so this freed enough bits. (I also renamed the fields to let the compiler find any usage of the old field name) |
|
|
We would have enough bits if we moved the function start pointer / inherit index out of the flags... And separating function from variable flags might be a good idea, too. |
|
|
If I remember correctly, we also thought that was a good idea some years ago for other reasons... |
|
|
suspended pending refactoring function and variable flags. ;-) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-03-10 17:49 | _xtian_ | New Issue | |
| 2010-03-10 18:44 | zesstra | Note Added: 0001782 | |
| 2010-03-11 03:05 | _xtian_ | Note Added: 0001783 | |
| 2010-03-14 11:26 | zesstra | Relationship added | related to 0000735 |
| 2021-04-12 00:42 | Gnomi | Note Added: 0002583 | |
| 2021-04-12 09:08 | zesstra | Note Added: 0002584 | |
| 2021-04-16 22:40 | zesstra | Project | LDMud => LDMud 3.7 |
| 2021-04-16 22:41 | zesstra | Note Added: 0002604 | |
| 2021-04-16 22:41 | zesstra | Assigned To | => zesstra |
| 2021-04-16 22:41 | zesstra | Status | new => acknowledged |
| 2021-04-17 10:34 | zesstra | Assigned To | zesstra => |
