01-12-2014, 05:16 AM
Why in the love of god would you make us (plugin writers) suffer with thread locks?
MCS objects are secured, API is thread-safe (at least proposed to be, and deadlocks are being hunted down), interplugin communication doesn't look to me like it would desperadely need locks.
Also, I don't really see a point in implementing handles. Should you make a handle and implement its states, this will end up with just as good as it would be without handles - with integrity checks before calling a plugin. From plugin's point of view there's no bloody difference between "plugin can't load, never ever forever whatsoever" and "plugin isn't ready for you, try later" - both cases end up in aborting dependant execution. And to be fair, it's not like plugins are "we have internal function that does stuff, but in this plugin stuff's done better, therefore we'll use theirs, but we can use ours as well, it's just not that good"-way. If plugin B needs plugin A, and there's no A to use - B can't work. End of line.
What would really bring good benefit to this is perhaps "OnPluginsLoaded" hook, proposed by xoft somewhere. We had this discussion (on github issues, I believe?), and now I'm convinced that that's where plugin reference getter should go.
MCS objects are secured, API is thread-safe (at least proposed to be, and deadlocks are being hunted down), interplugin communication doesn't look to me like it would desperadely need locks.Also, I don't really see a point in implementing handles. Should you make a handle and implement its states, this will end up with just as good as it would be without handles - with integrity checks before calling a plugin. From plugin's point of view there's no bloody difference between "plugin can't load, never ever forever whatsoever" and "plugin isn't ready for you, try later" - both cases end up in aborting dependant execution. And to be fair, it's not like plugins are "we have internal function that does stuff, but in this plugin stuff's done better, therefore we'll use theirs, but we can use ours as well, it's just not that good"-way. If plugin B needs plugin A, and there's no A to use - B can't work. End of line.
What would really bring good benefit to this is perhaps "OnPluginsLoaded" hook, proposed by xoft somewhere. We had this discussion (on github issues, I believe?), and now I'm convinced that that's where plugin reference getter should go.
(01-12-2014, 03:45 AM)xoft Wrote: Wouldn't it just be easier to change the plugin calling interface to a single function:Objection. Should plugin author decide to change plugin's name other plugins (especially if they rely heavily on that one, nd have dozens of calls) would have to rewrite every single call instead of one. IMO, potantial benefit of cleaning API just a bit doesn't justify a potential loss of easy adaptation.
local Ret1, Ret2, Ret3 = cPluginManager:CallPlugin("PluginName", "FunctionName", FunctionArgs);