positional vs named parameters

[William Edsall]

Hi,
 Just curious if the LDMud developers have ever considered using named function parameters instead of strictly positional parameters. To my knowledge, LDMud uses positional parameters today, is that correct?

Positional:

type function(parameter1, parameter2, parameter3) (must be in correct order)

Named:

type function(parameter2=x, parameter1=y) (order or omission doesn't matter)

When if we have functions with long lists of parameters we can worry less about providing default values and only provide the parameters we need to.

Maybe there are better solutions to this as well.

Thx
Gorgar @ Dragonfire

[Gnomi]

Hi Gorgar,

William Edsall wrote:
> Just curious if the LDMud developers have ever considered using named
> function parameters instead of strictly positional parameters. To my
> knowledge, LDMud uses positional parameters today, is that correct?

Correct. But I haven't seen, yet, a design how named function arguments
could be integrated into LPC. There was a discussion two years ago on
this list about that.

One of my main design points would boil down do this: How would a
call_other() sefun look like?

With best regards,
Gnomi

[William Edsall]

Gnomi,
 The concept feels similar to references. With references, you're referencing an lvalue.. but in this named parameter concept it would just be an lvalue in a different object and function correct?

Would a new operator do the trick similar to references? for example ~.

//local function
int test_local()
{
 int local_i = call_other(ob, "test_remote", ~i=2); //or ob->test_remote(~i=2)

 
 return local_i+1;
}

//remote function in 'ob'
int test_remote()
{
 int i;
 
 return i;
}

[Gnomi]

William Edsall wrote:
> Gnomi,
> The concept feels similar to references. With references, you're
> referencing an lvalue.. but in this named parameter concept it would just
> be an lvalue in a different object and function correct?
>
> Would a new operator do the trick similar to references? for example ~.

~ is already an existing operator in LPC. But how you specify named
parameters on the caller site is a minor point. The more interesting part is
on the callee site (how to specify arguments that cannot be named, can be
named or must be named parameters?).

And you didn't answer my question about the call_other sefun: Currently a
call_other simul-efun may look like this (I haven't tested this, so do not
C&P that into a real mud):

mixed call_other(object ob, string fun, varargs mixed* args)
{
set_this_object(previous_object());
return efun::call_other(ob, fun, args...);
}

The question of my previous email is: How would that look like, allowing
named parameters with ob->fun().

Greetings,
Gnomi.

[Invisible]

On 06.11.22 02:00, William Edsall wrote:
> Hi,
>  Just curious if the LDMud developers have ever considered using named
> function parameters instead of strictly positional parameters. To my
> knowledge, LDMud uses positional parameters today, is that correct?
>
> Positional:
> type function(parameter1, parameter2, parameter3) (must be in correct
> order)
>
> Named:
> type function(parameter2=x, parameter1=y) (order or omission doesn't
> matter)

There was a discussion about this here a while ago. Conclusion back then
was that it would be quite cumbersome to implement, mainly because of
call_other (where the compiler doesn't know the target function, as it
may come from a variable). But AFAIR it at least sparked the
implementation of default values for function arguments :-)

There are two easy ways around this in LPC though: simply pass a mapping
or a struct. Not exactly the same, but good enough. And the overhead
should be negligible in most cases.
IMHO named arguments are most suitable for optional, rarely used values.
If you find yourself in a situation where you have trouble keeping track
of your arguments, you're most probably passing too many arguments in
the first place (i.e. the function is doing too much and you should
consider splitting it up anyways). If that's not practical I more and
more find myself putting those rarely used things into an "options"
mapping at the very end of the argument list.

That said: maybe structs could be expanded for this purpose, so that the
fields get extracted into variables automatically. But I doubt that the
benefits are worth the effort. Plus it still doesn't solve the issue
with call_other, where the target function isn't known at compile time
and therefore the compiler cannot implicitly create a suitable struct.


cu
  Invis @ Beutelland