How can we encourage developers to build plugins based on other plugins?

I originally started this thread to discuss about cases where you should create plugins like "extensions" for other plugins so that not the whole plugin has to be created, e.g. if you want forums account support for auth, you create a plugin adding a DataProvider to SimpleAuth, not to create another auth plugin. Seems like the topic gets shifted to talking about less relevant plugins?

 

I have also heard that there is something called Vault in MCPC. It just allows dependency on one plugin that has soft dependency on many other plugins, so you just need to look at the API of one plugin.

(How come this discussion is getting further and further from what I was talking about? I was just talking about depending on a single plugin!)

 

Vault is purely an API standard. It will be terribly meaningless if we have tens of standards once again.

 

wait for someone to link for the XKCD
and that is how spoons came to be

5 competing standards = someone want to make a centralized standard
next month = 6 competing standards

 

This is harder than teaching people how to write plugins. A well-organized plugin always has its interface and implementation layers well-separated. I'm not talking about the pointless creation of interfaces like CommandMap in PocketMine - you don't need to create an interface for every class. My point is that if your code is written well, every method that you call in your commands should be something that can be used by all other plugins. For example, the Player->sendMessage() method in PocketMine was originally only for internal use, but it becomes the most popular API method used by plugins. It is because properly organized the code such that you just call a simple function to send a message rather than creating a packet and sending it every time. In this way, people can understand what you are doing easily just by looking a small amount of code. This also reflects that having extremely big functions is bad as the code is barely readable - if you need to put comments in front of a block/group of code to show what you are trying to do within a function, you should probably separate that block/group into a function. Such separation of functions will eventually turn into API functions, which can be utilized by other plugins as an API.

In addition, every time you ask yourself "Should I do something else here?", you should allow other plugins to do something there with the relevant data; for example, call a custom event or like the RegistrationStep in HereAuth or like the DataProvider in many plugins that support multiple types of databases.

Before you release a plugin, look at all private class properties. Are there any private class properties that should be exposed to or even editable for other plugins but is not possible yet? And, check if all your public functions do what they seem to do - for example, if you have an API method called setTeam(Team), does it really set the team or the player? Or does it only change the local data reference without modifying the data, which other plugins will try to use and find out that they aren't changing anything useful?

(Oops, I think I already created the thread you were talking about!)