Multiple User Functions With the Same Name

[holatuwol]

I thought I allowed for this several dozen releases ago, but it turns out that I didn't actually implement the final changes which would permit it at the user-level.  I've gone ahead and done so and the changes will be present in the next release of KoLmafia.

What this means, in regular terms, is that with the next release of KoLmafia, you can finally start giving your functions the same names, provided the parameters passed to these functions are somehow different.  You're even allowed to give them different return types, provided this "use different parameters or different numbers of parameters" condition is met.

For example, the following code will validate in the updated ASH interpreter and print "Integer!" followed by "String!":

void test_me( string s )
{    print( "String!" );
}

void test_me( int i )
{    print( "Integer!" );
}

test_me( 1 );
test_me( "Hello world." );

 

[efilnikufecin]

Awesome!!!, less conversions!!!

 

[efilnikufecin]

OK let me see if I got this right. A script I have contains this function:
(note not all function calls or variable declarations shown)

boolean buy_buff(int length, skill buff, string bot)
  {
  if(!buffbot_data[bot].initialized)
    {
    if(!init_bot(bot)){return false;}
    }
  foreach key in buffbot_data[bot].buffdata.buffdata
    {
    if(buffbot_data[bot].buffdata.buffdata[key].name == skill_to_string(buff)
       && buffbot_data[bot].buffdata.buffdata[key].turns >= length)
      {
      if(!buffbot_data[bot].buffdata.buffdata[key].philanthropic)
        {
        cli_execute("send " + buffbot_data[bot].buffdata.buffdata[key].price + " meat to " + bot);
        return true;
        }
      }
    }
  return false;
  }

and I want it to be able to take an effect rather than a skill so adding the following code should do it?

boolean buy_buff(int length, effect buff, string bot)
  {
  return buy_buff(length, effect_to_skill(buff), bot);
  }

then when this script is used into the gcli namespace the user would then be able to call the function with either the effect name, or the skill name and expect the same results. Am I correct on this, that a used script in the gcli namespace will allow the same?

What effect will this have on overriding built in functions?

 

[holatuwol]

Almost.

1. Functions don't need to return the same type.

2. The gCLI namespace isn't able to choose correctly because it has no context information.  It simply chooses the first one it finds with the right number of parameters and converts the strings to that and errors out on failure.

3. KoLmafia searches for functions in this order:

- Find a function defined by the user that matches parameter types exactly
- Find a built-in function that matches parameter types exactly
- Find a function defined by the user where there is a close match
- Find a built-in function where there is a close match

 

[efilnikufecin]

OK so for compatibility, I would need to work with strings, and convert them first,

boolean buy_buff(int length, string buff, string bot)

then add the following functions lower in the script so they will be found last and be specifically for importing into an ash script.

boolean buy_buff(int length, skill buff, string bot)

boolean buy_buff(int length, effect buff, string bot)

and finally build a string matcher which could decide if a skill name, or effect name was passed, and convert accordingly for the first function. This raises a yet another question. When imported into an ash script will kolmafia's built in auto string conversion kick in, and cause ash to use the first function anyway? if so, then the last 2 could be completely omitted, and the function I already have just get modified to handle a string.

 

[holatuwol]

The requirement of a string conversion falls under close match, not exact match. Alternatively, for gCLI namespaces, you COULD just make it so that there was a default turn count and a random bot choice and reduce everything to 1 parameter -- that way, the person would just type in "buy_buff antiphon" and the script would choose the default values you had preset. I imagine that someone who was doing gCLI wasn't looking for a specific turncount -- "enough" would be fine.