(03-05-2011, 03:11 AM)Tybor Wrote:(03-04-2011, 08:44 AM)Revolucas Wrote: Just reuse code for each one? If you release three plugins, not everyone is going to use all three. So if you are calling to other functions within those files it will not work. It's bad practice to do that. This really only affects someone who wants to customize their plugins for own use (You?).
Oh boy!
Reusing code in every plugin is bad practice! What do you think, why are there so called Runtime Libraries (*.dll or *.so) ?
The advantage about this programming practice is, that you can optimize, bugfix, change, add new features to the library without having to reimplement it in every plugin!
I'm saying if you are going to make plugin1.lua use functions or variables from plugin2.lua with the way you currently name functions and variables, unless it's just you who plans on sharing information between the two plugins. Because it's going to cause huge problems with name conflictions for other plugin makers. You have to make sure you don't let any variable names leak or Johnny Smith is going to flip out when he tries to make his plugin compatible with your economy plugin. Yeah, dlls...what does that have to do with trying to use functions from another plugin? You can require a .dll and use them just fine in lua. You could make make plugin1.lua and plugin2.lua require the same .dll file. You can even use a header.lua file and share functions between the plugins.
If you simply want to create an economy sort of plugin and use it in other plugins I suggest using SQlite. Plugin1 can check or alter the balance of a player directly if it also using SQlite or by calling the global functions within economy plugin if economy.lua is required, as long as it was implemented to do so. SQlite is more efficient and less messy then flatfile ini reading. In fact I insist you use it with your Area plugin, as flatfile reading for each area is very inefficient. SQLite is the best you can do without going to a full blown database.