Add vendor prefixes: rGuiName about raygui

[raysan5]

No plans to add vendor prefixes for the upcoming v2.0. Just closing this issue for now.

[raysan5]

Hi @inlife! Glad you like this little project! :)

Personally I don't like vendor prefixes, I avoided it on raylib and also would like to avoid it on raygui... but I'm concerned about the possible name collisions with other libraries (already dealt with that trying to include the infamous windows.h in raylib...).

In any case, I need to think about that... already considered using a rGuiName() in a similar way to raylib's rlgl module. As you said, it's a big change to the API (despite no many base-codes are using it, only some personal tools...).

EDIT: By the way, I'm following your librg library, considering it as a candidate library to add network functionality to raylib.

[inlife]

Well yea, however I think, when you are using something like raylib, you are using it not as a library but more like as a framework. Something bigger, something that defines global rules for your application, where you, as developer, is supposed just to follow them.

However that still won't save you from having name collisions with something having those simple method names. Easiest way would be to use namespaces, however as we know, C doesnt have those badboys :D

In any case, I need to think about that... already considered using a rGuiName() in a similar way

That is something what is definitely worth thinking about. And thinking quite a lot, I'd say. This is a major design decision, which in theory can be applied not only to the raygui, but for raylib and even raylib lua.

It's something that not just changes name methods, however makes a paradigm shift in your brain I suppose.

Anyway, for now I just suggest think about it, at least for a few weeks/months. That should give you, and others, answer "is this really worth it".

By the way, I'm following your librg library, considering it as a candidate library to add network functionality to raylib.

Oh that is so nice to hear. Thank you! I would also suggest looking into more low-level ENet library, we are using at as a backend in the librg.