In your example then those modules would be forced to be part of the system core. As a "plugin" module they would not qualify. As stated previously "many" is the key word here. Qualification to either category of "core" or "plugin" should have a line drawn.Carl, I couldn't disagree with you more. Carl McDade wrote: > In actuality the extension of a module in that manner should not happen. > This is against the whole concept of plugin modularity. Probably the > reason for the prolification of modules is that they are not autonomous > as they should be. Many of the present modules should be completed as > variants of the original an thus be able to relplace them entirely. What happens when you have two modules that append functionality to an existing module. If you do this then you would need 4 different files that administrators have to choose between to get functionality they want. e.g. example.module example_with_extension1.module example_with_extension2.module example_with_extension1_and_with_extension2.module Now how about 3? You do the binary math and you will see how quickly this could get out of control. And how do you maintain this? If something changes in example.module what do you do with [say] 127 different files that all have the same code embedded in them? This is the exact opposite of modularity. > This philosofy is one that is solid in other software industries but > only in parts of Drupal. Holding to it in the case of modules would > solve a lot of the problems with UI and and database modification. Solid? What you describe is unmaintainable bloat. andre