ID:2393337
 
Applies to:Dream Maker
Status: Open

Issue hasn't been assigned a status value.
Main goal of this request: When branching one codebase into another, procs should not allow the same proc to be redefined in multiple places. Right now, it's possible to have:


/object/child/proc/foo()

and

/object/child/foo()

defined in separate places and to function correctly. The redefined foo would have ..() call the previous foo. Which is a very bad idea unless it's a subclass of child, like /object/child/grandchild/foo. However, people insist on maintaining, as a feature, being able to fully override the default behaviour of any given proc without having to rename it or subclass the object. (See for example: https://github.com/Citadel-Station-13/Citadel-Station-13-RP/ pull/258#issuecomment-414237764 )


One proposal of how this might be done is to allow suffixing the proc keyword:


/object/child/proc/foo
Base

/object/child/proc!/foo
Number of exclamation marks determines how far up the proc is overridden. Forces coders to acknowledge already modularized code without it being unexpected behaviour. !!proc/foo for example would have ..() equal to proc!/foo

/object/child/proc./foo
An alternative to !, when ! is already used. If proc!/foo is used, use proc./foo. If proc./foo is already used, used, use two dots. Behaviour across dots is consistent, largest number of dots takes priority. Can subsequently be stacked with !. proc.!!/foo would ..() to proc.!/foo which would then go to proc./foo/ to proc/foo.

Examples of how higher-level reduction would happen:
.3 = ...
!3 = !!!
proc.. -> proc
proc!! -> proc! -> proc
proc..! -> proc.. -> proc
proc!.. -> proc! -> proc

And in a very rare situation where dots need to be stacked,
proc.3. -> proc... (or proc.3) -> proc
proc!.3. -> proc!... (or proc!.3) -> proc! -> proc


The dot and exclamation mark system primarily serves as a tree selection system. Exclamation marks dictate position zero, while dots any other position. This, in a tree of sub-codebases, allows any sub-codebase to directly specify which codebase's proc they intend to override, and thus which sequence ..() will call without being ambiguous.

This, however, assumes that a linear sequence of derived codebases will build up a tree one node at a time. If each derived codebase accepts all the codebases except the immediately precedent as unnecessary to touch, only exclamation marks should be used.
programming in dm isn't linear.
I'm talking here about when people fork other people's codebase and decide they don't want to change code written above, but still want to change the behaviour of a given proc.

Only the first two paragraphs actually outline my request. The rest is just an example of how it could be done.