Matchbox RC2

[eluser]esra[/eluser]
[quote author="sophistry" date="1196976416"]i think this idea of integrating a dependency checker is another instance of solving a problem that:

a) doesn't exist yet
b) won't be a big deal

just let module developers keep their modules up to date with the latest libraries. period. if the module changes the library changes.
the downside is clear and small: extra code to load.
the upside is huge: fewer variables to account for, less clutter in the module code, fewer hurdles for potential module developers.

imagine asking a module developer for help with a dependency setup like the one outlined above? talk about a nightmare...
imagine the documentation: now, build a version check function to account for the fact that someone else might have already installed the library you integrated.

that would turn me off completely from building modules.

kiss.[/quote]

Keep in mind that the installer is a module. Thus, any developer can choose to use it or not use it depending on their needs. Also, it might be possible to build other implementations over time that handle the needs of more complex applications or suites of applications.

There was Modular Separation 1.x.x, then Modular Separation 2.x.x, and now Matchbox 0.x.x (there was also Dynacheck, Zawk, and Zacharias all of whom are the same person). Although dependency checking might not be a problem for you, I'm sure it is a problem for some of us who need to correlate module versions with versions of CI as well as the versions of external libraries. CI development is slow at the moment, but this is probably going to change in the future based on EE objectives and goals. Modules built for CI 1.5.x might not work when 1.6.x or 2.x.x is released. At this point, who knows what the future holds regarding CI development. I use an external javascript library called EXT where the API has changed significantly over the past year. Thus, I now have dozens of modules that no longer operate correctly with EXT 2.0 and were designed for Modular Separation 1.x.x or 2.x.x and most of them need to be rewritten to take better advantage of Matchbox improvements.

Versioning should be optional for those who need it. The installer could be version aware if a config option is set to TRUE.

Regarding module dependencies in general, Dependency Injection (Inversion of Control) might be another solution to experiment with later after a PHP5 strict version of CI is released. To do this, the front controller and module controllers probably need to be extended from the same abstract class or implemented from an interface, allowing a container solution like the Java PicoContainer to be used. There is a PHP port of PicoContainer. Then a module could request its dependencies rather than including or requiring them. Of course there are pros and cons--much better for unit testing but a bitch to debug problems related to external dependencies.

Generally, I think config file options with preset defaults are a good compromise for most of your arguments.