Closed lihop closed 3 years ago
Now there's another reason for me to avoid class_name
...
Personally, I prefer the approach of adding underscore prefix. As it make sense even if the issue(Implement namespaces to avoid collisions in third-party add-ons #1566) is fixed in the future. And as mentioned that this approach doesn't fully mitigate the conflict, but I think the chance is so low that it is neglectable.
Thanks for the bug report!
After installing and enabling the ThreadPool plugin with the following
plug.gd
:Future invocations of the
plug.gd
script fail with the error messages:This is because the ThreadPool plugin declares the unique global class here:
which conflicts with gd-plug's inner class: https://github.com/imjp94/gd-plug/blob/83cd8f5409d98a54e0f2e02327bd9b869c2706a6/addons/gd-plug/plug.gd#L832
I can also see the potential for conflict with gd-plug's other inner classes.
Logger
with some logging related plugin, and (maybe less likely)GitExecutable
with some git related plugin.More widely, this is related to github proposal #1566 Implement namespaces to avoid collisions in third-party add-ons. A suggested workaround there is to add a prefix to class names.
Some ideas (assuming these inner classes are for private use only and not part of the pubilc gd-plug API):
ThreadPool
->GDPlugThreadPool
Logger
->GDPlugLogger
GitExecutable
->GDPlugGitExecutable
This is a little ugly but least-likely to conflict with other plugins.ThreadPool
->_ThreadPool
Logger
->_Logger
GitExecutable
->_GitExecutable
This marks the inner classes as private and keeps the pretty names. It shouldn't be too likely that these conflict with other plugins, but who knows. Perhaps another plugin developer might declareclass_name _Logger
orclass_name _ThreadPool
for whatever reason.