D 2018-07-04T13:52:53.684
L Rationale
N text/x-markdown
P d891dd7767261a8e46f3a306ce4650b5259432ec23b702b79cc06852b3d99af3
U mario
W 7571
## Purpose
Plugin meta data is intended for basic code extension schemes.
* Primary target are scripting languages.
* Where "plugins" can be contained within a single source file.
* It's just about the meta comment format however. There's no inherent
definition on how to tie application-level callback / hook / class APIs.
* Maintenance is simplified by having technical and description
attributes *embedded*.
* Foremost it's very discoverable and useful to end-users.
* Extensibility is a core feature. (This spec is just to define
some obvious standard fields.)
* And while that's not a goal, even can help with application packaging.
## Design Rationale
To make this suitable across programming languages, the syntax needed to
be generic and not be tied to specific docblock variants.
* Hence a consecutive `#` block is recommended as default comment style.
* Individual implementations are encouraged to support any alternative
comment block syntaxes.
* `key: value` fields are a rather obvious choice. And they're already
used in related specs (PKG-INFO, Debian control, etc.)
* Key names should be single `words:`, or RFC `message-header:` combinations
at most.
* They should never contain spaces, as that made it really cumbersome
to parse/process. (→ And that's how you get ants!)
* In some languages it's a rather unfortunate idiom to use "ASCII art"-style
comments. Often there's all sorts of personal variations like
"Written by:" or "Authored by:" and so on - due to lack of standardization
and language ecosystem.
* Which is precisely what the PMD spec is meant to help against.
* All basic fields are suitable to CLI tools, as well as GUI applications, or
web apps.
* Additions like `icon:` etc. can be used for more specific cases.
* `type:` is one recommended way to support the more widespread "hook" or
service locator systems.
* Albeit even `category:` or custom fields can be fitted for more complex needs.
* Utilizing PMD does not require *each and every* source script to carry a meta data
block.
* Obviously it's only meant to augment those code bits that represent
features or extensions.
* Though, of course; once you start classifying scripts, or have a huge
enough codebase - plugin meta data will appear even in core files.
(And I'd usually tag them as such - `type: core`)
* "Modules" are not scope of this spec.
* Of course, for "module packages", one could elect a primary/invocation
script, add plugin meta data only there, and leave the rest undocumented.
* Another essential feature of PMD is a common [config:](wiki/config) scheme.
* Many times plugins themselves represent just settings/adaptions.
* For more complex code it's very common to introduce new global application
settings.
* Rather than leave each plugin to also micromanage an UI for settings those,
defining a standard way to collect options (globally or on per-plugin basis)
is a neat gimmick.
* There's quite some overlap. But PMD has an entirely different scope than build/source-packaging tools (npm, pip, composer, etc).
* The plugin spec is meant for runtime configuration between individual scripts, not a global project recipie.
* With e.g. [depends](wiki/depends) being more of a recommendation than leading to dependency hell.
* Its scope is end-user discoverable documetation rather than build systems.
* Although one could generate/augment e.g. package.json from a list of `# depends: npm:xyz, npm:abc, …`
## Inspired by
Both syntax and usage didn't come out of thin air. There's lots of prior art
and things PMD tries to be compatible with to some extend:
* Standard field names mostly come from the Debian packaging spec.
Which is sort of a standard already. (No need for NIH field names.)
* One of the few things Wordpress got right (almost). They've been using
(or rather inherited) a similar comment-based plugin description scheme.
* Except for the abhorrent spaced key names, and not knowing what else to do with it.
* Most WP plugins have to define config hooks/settings/handling themselves
to this day.
* There's a few similar language-specific meta data schemes:
* JS userscripts use a constrained docblock-style scheme for similar purposes.
* TCL, teapot?
* ... (readd from old list...)
## Why not?
Before PMD came to be, I've also tried a couple of common mishaps:
**Meta-data in code**:
* Most intial extensions/plugin schemes (e.g. PHP4-era code) use
class constants, properties, or function hooks to register with
the application API.
* However such meta info code is just used in a one-off fashion.
Either once for installation, or rarely for option configuration.
It still might show up in menus, but otherwise is pretty much dead code.
**External .meta/.ini/.xml files**
* For binary apps / compiled languages, having a module description scheme
externalized is often unavoidable.
* But auxilliary meta files often just add complexity (copy and updating them
along the real code), not features per se.
* It's harder to eschew for broader "module" schemes. But for the purpose of slim
feature hooks, embeding meta infos turns out most practicable.
### DocBlock considered harmful
Most scripting languages use some form of DocBlock, PerlDoc variants, decorators
or any custom API documentation scheme. They're quite essential or even existential
or function/class-level description.
Not so much for file-level docblocks however. Those decorations rarely add anything
worthwhile to autogenerated docs. Which would have been a great reason to repurpose
DocBlocks for PMD with an established syntax, but:
* Most DocBlock parsers trip over custom attributes. A few would just yield a bunch
of warnings. But generally there's no support for anything but textual descriptions.
* The well is poisoned with boilerplate. Due to being this widely adopted, IDEs
started adding boilerplate DocBlocks. Which contributed to its diminished usefulness.
* Variations across languages (PerlDoc vs JavaDoc) also would have made DocBlock
look out of place as default syntax for plugin meta data.
Another dealbreaker was the excessive pairing with...
### The great license plague of the 90s
License blobs in lieu of proper file-level documentation.
* Now to be fair, most academic/attribution licenses recommend them to be embeded
with source code. (None require this to be at the file start though.)
* For reciprocal licenses, which do not apply on a file-by-file basis to being with,
this is entirely unfounded. Nonetheless it became a toxic habit to plaster source
code with license excerpts - oftentimes to avoid effort on actual code descriptions.
* It's an abomination of the purpose of code comments.
PMD mandates to be in the first comment block in order to combat exactly this. The
intend behind the [license](wiki/license) standard field is to legitimize SPDX identifiers
instead.
Z e61207d77a17cbec2c9e1284b63d4ea9