Codegen: remove Im* prefix restriction on structs

[gucio321]

Idk why was that restriction there, but after removing it, much more function is generated

[AllenDang]

As i recall, Im* prefix means that struct kind of public and without that prefix means it's internal

[gucio321]

As i recall, Im* prefix means that struct kind of public and without that prefix means it's internal

Oh, ok I see, but, since #99, we should generate everything internal, shouldn't we?

[AllenDang]

@gucio321 Frankly, I think auto-generator should respect the public/private rule in imgui (an API is marked as private for a reason I think). If some internal API is really needed for a good reason, one could export it by hand like util.h, util.cpp and util.go did.

[gucio321]

@gucio321 Frankly, I think auto-generator should respect the public/private rule in imgui (an API is marked as private for a reason I think). If some internal API is really needed for a good reason, one could export it by hand like util.h, util.cpp and util.go did.

@AllenDang I see, but I think we should change this attitude for a few reasons:

• we already expose everything from imgui_internal (which is supposed to be unexported I think)
• consider C privacy rules: despite something is intended to be private, it is not private in fact (if developer needs it, he can use it). In go it is arbitrary detemined whether something is public or private

Thats why I suppose we should have everything exported, notify our users, that something is not supposed to be exported in imgui (e.g. add a comment over function/type declaration or prefix it with Internal) and let them decide whether they want to use it or not. Over that I suppose that if someone uses cimgui-go he is rather familiar with C++ version and knows consequences of using internal stuff.

[AllenDang]

@gucio321 Frankly, I think auto-generator should respect the public/private rule in imgui (an API is marked as private for a reason I think). If some internal API is really needed for a good reason, one could export it by hand like util.h, util.cpp and util.go did.

@AllenDang I see, but I think we should change this attitude for a few reasons:

• we already expose everything from imgui_internal (which is supposed to be unexported I think)
• consider C privacy rules: despite something is intended to be private, it is not private in fact (if developer needs it, he can use it). In go it is arbitrary detemined whether something is public or private

Thats why I suppose we should have everything exported, notify our users, that something is not supposed to be exported in imgui (e.g. add a comment over function/type declaration or prefix it with Internal) and let them decide whether they want to use it or not. Over that I suppose that if someone uses cimgui-go he is rather familiar with C++ version and knows consequences of using internal stuff.

Ok, you got me, let's do it, expose everything

[gucio321]

greate, so @AllenDang so go ahead and get it merged!

[AllenDang]

LGTM