Currently, if you want to use named args in a proc on an object that has children, any children that override that proc MUST explicitly include all the named args of the parent proc to be assured to work. If said proc is a high-level one common to override (such as New()), this can get overwhelming very quickly. And adding a named arg to a high level of such a proc requires updating every single child, all the way down the tree, even if they don't use the arg in the overridden code.
This can be avoided by providing a parameter list rather than directly using named args, but this is unintuitive and introduces extra overhead.
There are several potential solutions. The following are ranked from best to worst, in my opinion:
1. Any proc which calls ..() does not throw the bad argument runtime, and just passes the arg up the chain. The runtime would still be thrown if the first proc reached that does not call ..() doesn't have the argument.
2. Add a syntax that specifies that a proc should also accept any args its parent possesses. Essentially, add its parent's list of args to its own AFTER the part of compilation that checks if variables are defined. This would have the result of allowing automated inheritance of named args, without ruining readability by allowing use of an arg not specified in the prototype as pictured below. Obviously, args added this way should only be usable as named args.
3. Add a syntax that tells the preprocessor to directly add the parent's list of args to its own. This would work, but would allow for readability nightmares such as this:
/atom/movable/proc/jump(dist = 1)
//Do whatever
//And then off in some entirely different file:
/mob/jump(.., silent = 0) //Or whatever syntax you want
..()
if(!silent)
msg_viewers("[src] jumps [dist] meters!")
The above would be even worse if the var in question shared a name with a var on the object to which the proc belonged, but I couldn't bring myself to do that.
The point is that number 3 is a pretty awful solution, and the others would be greatly preferable.
Syntax: The first option doesn't require any special syntax, but I understand it may not be feasible due to internal differences between named and positional args, or something.
The other two could use a syntax like above, with some special token being used in the prototype, with the args. Alternatively, it could be a setting, like a verb's name. Really anything would work.
