View Issue Details

IDProjectCategoryView StatusLast Update
0000734LDMud 3.7LPC Languagepublic2021-04-17 08:34
Reporter_xtian_ Assigned To 
PrioritynormalSeverityfeatureReproducibilityN/A
Status acknowledgedResolutionopen 
Summary0000734: warn_nomask modifier
DescriptionAnd 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.
TagsNo tags attached.

Relationships

related to 0000735 closed LDMud pragma warn_only 

Activities

zesstra

2010-03-10 17:44

administrator   ~0001782

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.

_xtian_

2010-03-11 02:05

reporter   ~0001783

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)

Gnomi

2021-04-11 22:42

manager   ~0002583

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.

zesstra

2021-04-12 07:08

administrator   ~0002584

If I remember correctly, we also thought that was a good idea some years ago for other reasons...

zesstra

2021-04-16 20:41

administrator   ~0002604

suspended pending refactoring function and variable flags. ;-)

Issue History

Date Modified Username Field Change
2010-03-10 16:49 _xtian_ New Issue
2010-03-10 17:44 zesstra Note Added: 0001782
2010-03-11 02:05 _xtian_ Note Added: 0001783
2010-03-14 10:26 zesstra Relationship added related to 0000735
2021-04-11 22:42 Gnomi Note Added: 0002583
2021-04-12 07:08 zesstra Note Added: 0002584
2021-04-16 20:40 zesstra Project LDMud => LDMud 3.7
2021-04-16 20:41 zesstra Note Added: 0002604
2021-04-16 20:41 zesstra Assigned To => zesstra
2021-04-16 20:41 zesstra Status new => acknowledged
2021-04-17 08:34 zesstra Assigned To zesstra =>