GameMonkey Script

GameMonkey Script Forums
It is currently Wed Aug 15, 2018 1:38 am

All times are UTC

Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Sat Feb 27, 2010 1:02 am 

Joined: Sat Apr 25, 2009 1:40 am
Posts: 66
gmCall and gmMachine::ExecuteString/ExecuteLib/ExecuteFunction

In gmCall, the method to call a GM function looks like this:
bool BeginFunction(gmMachine * a_machine, gmFunctionObject * a_funcObj, const gmVariable &a_thisVar = gmVariable::s_null, bool a_delayExecuteFlag = false)

but in gmMachine the method looks like this:
int ExecuteString(const char * a_string, int * a_threadId = NULL, bool a_now = true, const char * a_filename = NULL, gmVariable* a_this = NULL);

The delay flag is the opposite and the "thisvar" is a pointer instead of a reference. I personally prefer the way gmMachine::ExecuteString does it (using a pointer for the thisvar)

Another one is gmThread::ParamInt(int a_param, gmptr a_default) and gmVariable::GetIntSafe().

gmThread::ParamInt() doesn't work if the value is a float, but GetIntSafe() does. Also gmThread::ParamInt() allows you to pass your own default value while gmVariable::GetIntSafe() will just return 0. The same for ParamFloat. I think gmThread::ParamInt() should work on floats, and gmVariable::GetIntSafe() should be able to accept default values

Reply with quote  
PostPosted: Sat Feb 27, 2010 1:32 pm 

Joined: Mon Dec 15, 2003 1:38 pm
Posts: 703
Just a few thoughts...

Yes, the interfaces are inconsistent. They evolved over time without regard to consistency and that is unfortunate. Because of that it may be best to perform a API wide 'cleanup' at some stage when a new version is worth updating old code. A future v1.5 or v2.0 would necessarily cleanup a LOT of niggly things that were simply not considered at the time.

The gmVariable class has a variety of utility functions. I tended to use verbose names like GetIntSafe() which allows the user to immediately see what the function is and the performance trade off. I suggest here that you add your own functions to it inside some #defines (purely to highlight and track your own changes.) Eg. Plain Int() Float() functions with as few or many overloads or default params as you like. I think a set of default param type checking accessors is probably a good idea to complete a common interface, to supplement non checking ones etc. I haven't needed them before myself and I think that is because beyond int<->float types, I think a mis-typed (or missing) variable should be handled as an exception rather than silently ignore and pass default.

The gmCall class is an example utility class. I suggest you add or change functionality or use it as an example to make a call wrapper that fits you needs.

Re-reading your post, I see you are comparing gmThread function parameters with gmVariable value accessors. They really are two very different things. The gmThread class supplies parameters to bound functions and thus parameters may be missing or overloaded, however type checking here is critical. The gmVariable class encapsulates a value or object and accessing its type or value in the existing ways is reasonable.

To clarify my thoughts, I'm not suggesting the API doesn't need a consistency cleanup or that I won't do so in my distro. I am suggesting that when you find something in gm that is not as good as it should be, or is missing, add it yourself using the existing code as a guide and see how it works out for you. Then share your findings and code here. Certainly continue to point out such inconsistencies or omissions here :)

Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group