Idea
The analyzer is scanning the source code for calls to the tombstone function. This is how the analyzer gets it's list of "active tombstones". There might be reasons why you'd want to generate the list differently, or extend the list with additional tombstone locations* which cannot be detected by the extractor. A configuration option to register a custom extractor would be the solution.
(* One idea that I had for this was "virtual tombstones". Creating a tombstone that is actually not in the source code, but pretend as if it was there. For example you want all "Controller" classes automatically tagged with a virtual tombstone and every time the application calls a controller, you programmatically log a call to that virtual tombstone. You would get a report that shows which controllers are in use.)
If this idea would be useful to you, give it a +1
Idea
The analyzer is scanning the source code for calls to the tombstone function. This is how the analyzer gets it's list of "active tombstones". There might be reasons why you'd want to generate the list differently, or extend the list with additional tombstone locations* which cannot be detected by the extractor. A configuration option to register a custom extractor would be the solution.
(* One idea that I had for this was "virtual tombstones". Creating a tombstone that is actually not in the source code, but pretend as if it was there. For example you want all "Controller" classes automatically tagged with a virtual tombstone and every time the application calls a controller, you programmatically log a call to that virtual tombstone. You would get a report that shows which controllers are in use.)
If this idea would be useful to you, give it a +1