3

There are lots of applications like 3ds Max, Maya, etc that allows you to use plugins, where even the default nodes are created as plugins.

This is all good but if the developer changes the class/type name of any node, then all the files using the previous version breaks.

It's like you commit to a name and that name cannot be changed. I am not an expert in designing these systems but wouldn't it be better to use some other info like a GUID for every plugin to create this link between which plugins are being used in a file?

So if you have a node like "deform", and later you realize "bend" is better, and you rename it, then everything still works fine. Note that in these systems, there are class/type names and Labels, I am talking about the former, as changing Label names doesn't break anything.

But the node class/type is still used everywhere in the app visually so seeing "deform" in those places but "bend" in a few other UI elements would be confusing.

I just thought GUIDs would allow you to basically bind the type/class of a specific plugin to its instances used in files without the issue of collision with other plugins.

  • How do you know software does not already work the way you describe? – user22815 Apr 17 '15 at 13:19
  • Because when the type name changes, all files using this node breaks. I am talking about the software mentioned above which I am using every day. – Joan Venge Apr 17 '15 at 13:21
  • Those examples are not just examples, then? You want to know why their authors chose to implement the plugin structure they did, given the drawbacks? – user22815 Apr 17 '15 at 13:25
  • 1
    No, I see this kind of restriction in many other software. I am just wondering if what I suggest is a better way to achieve this, if not why. Also how do software that let's you to change any of these info like type names, etc without breaking anything achieve this? Maybe my idea of using GUIDs is not smart, and there is a better way used by other apps. I definitely believe the apps I listed above didn't do it right. I don't know what this problem/solution is called either so searching is not easy. – Joan Venge Apr 17 '15 at 13:29
3

While this is a bit subjective, there are good reasons for using a GUID or other value that is not coupled to the name of a plugin.

You allude to the fact that there are several global properties to a plugin:

  1. A label, which is user presentation. This does not change the identity of the plugin and may change, for example, due to internationalization.
  2. Plugins must also have a class or function that loads it and makes it "go." This is a source code identifier.
  3. Plugins should have a static ID such as a name or GUID. This is what you are asking about.

Clearly, the first two identifiers are not optimal. One is user-facing and mutable, the second has specific implementation problems (e.g. C++ name mangling). However, in languages such as Java and C# with pervasive namespacing through packages that is mitigated somewhat, but still less than ideal.

The third option is clearly superior. If a plugin or class name changes, the plugin is still identified as installed and needing to load. Preferences are still linked.

Why go with a GUID over an arbitrary name? A name may have trademark or copyright implications that force the author to change it. Perhaps a plugin's scope changes, making the name inaccurate. Maybe the name translates to something taboo in a foreign language. There are plenty of reasons.

GUIDs get around these issues. Practical limitations aside, they are pretty much guaranteed to be unique, are not real words in any human language, and should never need to change.

As to why any particular software program uses whatever method they use to identify plugins, you need to contact the program's authors. If I were writing a software that implements a plugin framework today, I would use GUIDs.

  • I like your answer! ... but I think you overlooked a very crucial detail about these plugins. They are registering new functions for programmers to invoke via other plugins or script. It's analogous to us writing new functions in code and trying to come up with a good name that makes sense that other developers will use to call our function. GUIDs aren't necessarily so nice in that case if we started naming our functions like f0dbb9b8582c474ea899d4f66bf76040 to avoid possible cultural taboos or clashes. The names strictly serve this purpose -- they're programmer identifiers. – user204677 Feb 1 '18 at 8:44
  • Internally in Maya at least, the plugins have a unique ID for the purpose of loading and unloading. The names they register are just that, programmer identifiers so that other programmers/scripters can invoke their functionality. The idea of a GUID for importing a library of functionality is interesting and maybe not too cumbersome, but it's a bit awkward because sometimes these plugins just register one command or function. They're not always bundles. – user204677 Feb 1 '18 at 8:49
  • So there's a 4th aspect to these plugins. They add new functions to the software (not just to load the plugin but things like commands and node operators to be directly invoked in the scripting console with the scripter immediately being able to invoke such functionality by its identifier), and that's where the names are actually used that op is talking about. – user204677 Feb 1 '18 at 8:53
2

Why don't we use GUIDs for our programming languages?

f0dbb9b8582c474ea899d4f66bf76040("hello world!")

... or this:

import f0dbb9b8582c474ea899d4f66bf76040 as console_output
console_output("hello world!")

That would allow the authors to change their mind all they want about the user-friendly label associated to the GUID instead of using a name like print which might clash with something else or they might later prefer to call console_out. They can still document f0dbb9b8582c474ea899d4f66bf76040 as a "print" function, later change their mind and call it whatever they want in the documentation, still associate a user-friendly name in the IDE when you hover over the code. All we have to do in response is make sure all the code we write uses f0dbb9b8582c474ea899d4f66bf76040 or an alias we give it very locally in our code which then allows the libraries to associate any user-friendly name they want and keep changing their minds without breaking our code.

And hopefully you see the very immediate problem there, though I actually had to explain this to my team of VFX professionals a hundred times or so and repeatedly across meetings and the topic just kept coming up each year, so maybe I'm really bad at explaining this!

Programmer Identifiers, Not Just User-Friendly Labels

It's like you commit to a name and that name cannot be changed. I am not an expert in designing these systems but wouldn't it be better to use some other info like a GUID for every plugin to create this link between which plugins are being used in a file?

Plugins for software like Maya are not strictly providing features for users. They're providing functionality for programmers. The exact same reason we might not want to use GUIDs to name our functions above is the exact same reason why all these packages avoid GUIDs for class names, command names, etc. They're meant to be programmer-friendly identifiers directly referenced in code. The names are referred to in MEL scripts, Python, in other plugins, to alleviate the burden of the scripters and other programmers from having to refer to that thing via something as cumbersome and hard to read as a GUID.

So GUIDs are great if you just want to preserve uniqueness, but if you want to write code (ex: MEL scripts) and things like that which refer to an identifier, it'd be a real PITA to refer to things by GUID. So the practical alternative there if you want to refer to names in the first place already without exposing these GUIDs to scripters requires that the plugins register unique, relatively programmer/scripter-friendly identifiers.

So just like when we introduce new functions or classes into a codebase, we have to be careful how we name them, especially before they start racking up many dependencies. And GUIDs don't help here when our goal is to create meaningful identifiers for our classes and functions so that other programmers can use them. GUIDs would just obfuscate everything for everyone. But you can kinda use GUIDs if you want if you take out the dashes (could be confused for subtraction operator) and make sure the identifier starts with a letter, or simply jam the keyboard like udshvuidhsfauishfdsihuxczv and name your functions and classes that way to ensure a fairly good probability of uniqueness if uniqueness is more important than the readability of the code.

I just thought GUIDs would allow you to basically bind the type/class of a specific plugin to its instances used in files without the issue of collision with other plugins.

They do and if all you needed was to register something that few things refer to while you add a nice user-friendly, localized GUI label on top, then GUIDs make a lot of sense. But they don't make so much sense to use for programming identifiers (at least it would be quite a burden on the programmer to deal with GUIDs in their daily code just so that the author of the function or class is given more leeway to change his mind about the name of the class or function), and in Maya those names are just that: programming identifiers. Those new nodes aren't just features but also things that can be invoked via script.

Maya is kind of like a visual development environment. The plugins aren't just adding end-user features but new functionality which other developers can use/call/execute/invoke by name (identifier) to build more functionality. If Maya wasn't that kind of uber-scriptable and programmable environment, probably GUIDs would make a lot of sense. And ZBrush is an example of a software that I believe uses GUIDs or something similar (saw these big IDs associated with UI elements when they offered debugging features for scripters), but ZBrush is more purely artist-oriented so it doesn't bother with a plugin architecture (just ZScript which is very simple scripting). Maya is very TD and scripter-oriented. But given the way it is, those node class names are identifiers for other programmers to refer to by name.

GUIDs for Namespaces?

The idea of replacing the analogical namespace with GUIDs is interesting, like f0dbb9b8582c474ea899d4f66bf76040 instead of namespace std in C++. Maybe that wouldn't be too cumbersome if we used using declarations and directives liberally to import everything. The problem however with VFX software is that many plugins often just register a command or two, e.g. They don't necessarily add a whole bundle of functions to the software and very often just add one. So we'd end up having to deal with a boatload of GUIDs and quite often would have to copy/paste a new one (at least I assume most of us mortals would have to copy and paste, since I could never memorize a single GUID let alone hundreds) just to use one new function.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.