Add before/after properties to allow modules to specify default prioritization

[ruipin]

As it stands, modules are unable to signal a desired prioritization other than "WRAPPER", "MIXED", and "OVERRIDE".

A suggestion that has come my way is to add optional before and after constraints that will be used to decide on default prioritization. These would be lists of module IDs (or a single module ID), which would run by default before/after the given wrapper.

Example:

libWrapper.register("module-a", "Foo.prototype.bar", "MIXED", {before: "module-b", after: ["module-c", "module-d"]});

Optionally, we could have the dictionary be the third parameter (when it is not a string, for backward compatibility), and have the wrapper type be one of the dictionary values:

libWrapper.register("module-a", "Foo.prototype.bar", {type: "MIXED", before: "module-b", after: ["module-c", "module-d"]});

The user could then be warned if these constraints conflict (including when it's because the users themselves changed prioritization).

[caewok]

Adding my support for this suggestion. I have a pretty good use case in mind: I am working on a module that would act as a library for certain distance measurements. The trick is, though, who goes first can matter quite a bit when figuring out distance in a quasi-cooperative manner. Instead of trying to track this through some sort of Array, it would be simpler and cleaner if modules could just flag order in some manner. If that could be done, each module could simply wrap the distance function and add on their calculations in their specified turn. Everyone who does not participate would be relegated to last (or better yet, not at all if a given flag is set).

[ruipin]

For such a specific use-case, something handled directly by your library would probably be better. There's too many variables to rely solely on libWrapper, IMO.

I'd suggest you wrap the methods youself, and provide other modules with an API to register their own roll handlers that your wrapper then calls.

It doesn't mean this approach you suggest wouldn't work, but I think it wouldn't be very flexible IMO. Also, this issue isn't high priority, there's a few other things I think are more important, such as #33