🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Enumerating global property
Hello.
I'm in the process to replace my console-code with angelscript.
I use RegisterGlobalProperty() to expose some variables. Is there a way to let angelscript enumarate those variables at a later point?
I was thinking GetGlobalVarName() would do the trick, but I suppose it only works for variables defined inside some script.
I used to have a getVars() function, which listed all registered variables. It is nice and in a way auto-documenting to have something like that.
Is there a way to let angelscript handle stuff like that for me?
Thanks.
AngelScript currently doesn't let you enumerate properties, functions, etc, that have been registered by the application. I used to think that the application should know this already anyway, but situations (like yours) have made me think otherwise. I'll probably change this in a future version, but for now, you'll have to keep track of what you registered on your own (unless you feel like modifying AngelScript).
Regards,
Andreas
Regards,
Andreas
This would indeed be a handy feature.
Sure the app should know it, but how else can you display the list of functions etc to a user without creating a separate list of them.
Sure the app should know it, but how else can you display the list of functions etc to a user without creating a separate list of them.
Allright, thanks for the answer.
EDIT:
I wonder, are there any plans to include implicit int -> bool conversion?
Could be nice.
[Edited by - B_old on March 21, 2006 11:45:16 AM]
EDIT:
I wonder, are there any plans to include implicit int -> bool conversion?
Could be nice.
[Edited by - B_old on March 21, 2006 11:45:16 AM]
I've already implemented my own system to do this, and here's a rough description of what I did.
I have my own class as a member of my main engine class for managing anything script related. I call this the "script manager." The script manager contains wrapper functions for many of the angelscript functions, mainly the RegisterX() functions. Any call to register an object/variable/function/event registers it through these proxy functions. These functions build a hierarchy of all registered items into a data structure. My tools then uses this hierarchy information to construct various ways to visualize the registered items.
As a side not, I'm of the opinion that using implicit conversion for boolean operations is bad coding style. Take the following line of code:
if (somevar)
{
...
}
At a glance, it could mean any of the following:
bool somevar;
if (somevar == true)
{
...
}
int somevar;
if (somevar != 0)
{
...
}
int somevar;
if (somevar > 0)
{
...
}
char somevar;
if (somevar != '\0')
{
...
}
sometype* somevar;
if (somevar != NULL)
{
...
}
Using explicit boolean expressions for comparisons leads to code that is easier to read and tends to be a lot less error prone, imo.
I have my own class as a member of my main engine class for managing anything script related. I call this the "script manager." The script manager contains wrapper functions for many of the angelscript functions, mainly the RegisterX() functions. Any call to register an object/variable/function/event registers it through these proxy functions. These functions build a hierarchy of all registered items into a data structure. My tools then uses this hierarchy information to construct various ways to visualize the registered items.
As a side not, I'm of the opinion that using implicit conversion for boolean operations is bad coding style. Take the following line of code:
if (somevar)
{
...
}
At a glance, it could mean any of the following:
bool somevar;
if (somevar == true)
{
...
}
int somevar;
if (somevar != 0)
{
...
}
int somevar;
if (somevar > 0)
{
...
}
char somevar;
if (somevar != '\0')
{
...
}
sometype* somevar;
if (somevar != NULL)
{
...
}
Using explicit boolean expressions for comparisons leads to code that is easier to read and tends to be a lot less error prone, imo.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement