Magento

It seems to me the architecture of Magento could cause some problems when using multiple extensions.

Consider this:

- Person A writes a module and needs to extend the product model with a new function. He makes his own product model class, extending Mage_Catalog_Model_Product, and in config.xml he adds a rewrite tag to make Magento use his class.
- Person B writes another module, and also needs to extend the product model, and he makes a rewrite exactly as person A did.
- I want to install both modules, but it’s not possible since the configuration will use either class A or B and not B extends A extends Core.

Any thoughts on this? Should we avoid making subclasses of core classes and in that case, what can we do instead?

I’ve been wondering about this too. I guess the alternative is to use Magento’s event observer system as much as possible since that doesn’t suffer from the same problem. However, this is not always possible.

Well, it’s only logical that if 2 modifications extend the same class, you’d need human intervention to decide which one should have a precedence.

In this case integrator would make class with less precedence (A) extend the core class, and class (B) that should override methods in A would extend it.
The rewrite in configuration would have class B.

After each upgrade the change will need to be repeated.

Unfortunately, PHP doesn’t allow dynamic inheritance, so not too much options that i see here..

Maybe it’s possible to make a script that:
1. senses if 2 modules rewrite the same class
2. gives list of conflicts and asks for choice
3. updates the files and configuration
4. remembers the choice as a macro file to be repeated after upgrade.

mmm… maybe that’s just too much to ask and we should just do it manually

I’m just a little disappointed that I can’t add a small feature to a core module without blocking other extensions from doing the same thing. I hope they will add more events so we can use the event observer method more.

Solution to this problem would to convince Varien to use dependency injection pattern when dealing with rewrites.
Rewriting module should be given current rewritten class instance as a param (instead of extending it).
At that point, utilizing magic __call method would cause all changes to propagate, and in the end we would have a nice composition of non-conflicting objects, that could be used by anyone.

best regards
PiotrN