0000734: warn_nomask modifier - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0000734	LDMud 3.7	LPC Language	public	2010-03-10 16:49	2021-04-17 08: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.

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. ;-)

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 =>