Replaced fixed order with dynamic ordering

[bmomberger-bitovi]

For #271, the automatic addition of data/callbacks when the real-time behavior is used, was a desired feature of can-connect, and necessitated some way for real-time to declare that it needed another package included while still preserving order. this changes the ordering code so individual behaviors can decide where in the order they should go, and allows other connect behavior authors access to this ordering.

• This isn't quite ready yet, because the dependency objects are generally rather ham-handed, mostly deriving from the lines of order previously listed in connect.js plus some trial and error. Also tests have not yet been made for the new ordering code and for required deps.

• Pursuant to the previous bullet point, a pain point about can-connect (that the dependencies between behaviors aren't clear from the docs or code, due to the relationship between behaviors stems from shared property names) can be somewhat remedied by using the dependency object to show where ordering must be enforced.

• The dependency from one behavior to another may be in either the "base" direction (from object to proto) or the "derived" direction (from proto to containing object), and may be "optional" (enforce order if both behaviors are included) or "required" (if A is included then include B in the correct order).

[justinbmeyer]

the behaviors shouldn't know about each other, this seems to create that situation?

[justinbmeyer]

The idea behind can-interface is the dependencies should be on the method/property instead of a module.

[bmomberger-bitovi]

What problem is solved by behaviors not knowing about each other?

[justinbmeyer]

Other implementations of those behaviors can be provided.

Sent from my iPhone

On May 3, 2017, at 11:43 PM, Brad Momberger notifications@github.com wrote:

What problem is solved by behaviors not knowing about each other?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[bmomberger-bitovi]

That doesn't change if behaviors reference each other by key as this PR does. Reimplement with same key => order preserved (by the list in existing code; by the inbound deps in this PR); Reimplement with different key => order can be determined by mutating connect.order in existing code, by declaring dependencies in this PR.