wpsharks / core Goto Github PK

We should try to enhance the core by making it as IDE-friendly as we can.

i.e., With respect to dynamics that fall outside of what many IDEs are capable of understanding based on project structure alone. For instance, adding an _ide.php file to the core, or maybe even to the skeleton for new projects.

Versioning the websharks/core and websharks/wp-core is a tricky thing to deal with. Tricky why? If a piece of software bundles the websharks/core, it is going to depend on this being at a specific version of the websharks/core.

Conundrum?

• Imagine software package A (depends on websharks/core).
• Imagine software package B (also depends on websharks/core).
• Imagine software package C (depends on package A and package B, and also on the webshares/core).

So, we can see in this example that it is possible for A, B, and C to all be working together in a single process. What happens when package A was coded for version 1.1 of websharks/core, package B was coded for version 1.2 of websharks/core, and package C was coded for version 1.3 of websharks/core?

When I say, "coded for", I mean that a specific version of the websharks/core may behave a bit differently. One version might come with functionality that a previous version did not have, etc, etc.

Of course we will work to update packages A, B, and C so they are all compatible with the latest/greatest core; but this will not always be the case at all times; i.e., software we distribute needs to be capable of working as it was designed, even if package B is updated to use the latest version of the websharks/core, while packages A and C still need to be updated.

WordPress Example

Imagine package A, B, and C are all WordPress plugins; i.e., all being loaded into a single process. It's the same situation as I outlined above, but it becomes a little clearer when thinking about it this way.

SPL Autoloading To the Rescue?

No. A PHP class (i.e., class, interface, or trait) is an identifier. It is either loaded or not. If the websharks/core comes with class X, and it is not loaded yet, PHP will autoload that class file using one of the currently registered autoload handlers.

The problem, again, is that class X could be loaded from one of three possible locations. Either from software package A, B, or C. Depending on which of these are used to fill the autoload request, a different version of the class file might be loaded; and thus shared by all packages.

If package B is using the latest version of the websharks/core, and it fills the autoload request, packages A and C might cause an error, because they are expecting to see a different version of the websharks/core; i.e., the version they were originally built for and tested against.

Core Dependencies

Understanding how the websharks/core and websharks/wp-core are going to be used is key. These are not simply dependencies; these core libraries are going to be used as a base to start from, and then a software package is built from that base by extending classes and/or utilizing utilities provided by the core. Therefore, it is important that each software package be connected to a specific version of the websharks/core. When it is possible for the core to updated in that package, we can do so; but not before! Certainly not at runtime by accident; i.e., when another package happens to load a different version of the websharks/core.

Possible Solutions

• Use PHP v5.4 Traits and name each trait with a version suffix. This makes the core more difficult to maintain, and it requires a lot of search/replace whenever the core itself is updated. The same whenever a package is updated that relies on a specific version of the core.
• Use class aliases together with a custom autoloader that can distinguish one version from another. This is not ideal, because class aliases are more difficult to work with in IDEs that are unaware of such things. Also, this makes the core harder to work with too, because every change will require a version bump in the name of each Trait.
• Use the core not as a dependency at all, but as a library that becomes part of each software package, and each software package would include a build script that alters the namespace of all core packages; i.e., core libraries are used as a base, but renamed; becoming a part of each software package it is used in. The big downsides here are that it's not nearly as clean, harder to maintain, and we lose the optimization that having a central "core" library would offer.
• ... I'll add other ideas here as they come to me.