hi,
just had a thought for a nice feature that i don't remember having come up here before:
for a function with lots of optional arguments it would be nice to take a mapping and splice it up into the args:
void foo(void|string s, void|int i, void|float f)
could be called as:
foo( @([ "f":5.3 ]) )
usefull?
greetings, martin.
Keys in mappings are unordered so the only thing linking them to the corresponding formal parameters of foo() is (in this case) the name "f". However, that makes it impossible to rename "f" in foo() without breaking existing calls.
fair point but that problem you also have if you use a mapping and expect it to have certain keys (like in Process.create_process()) you can't rename the keys.
granted, currently the "problem" is limited to functions where such a mapping is used, but i don't see what the ability to rename your arguments buys you. you'll rarely want to change them if you are not changing the interface anyways.
greetings, martin.
granted, currently the "problem" is limited to functions where such a mapping is used, but i don't see what the ability to rename your arguments buys you. you'll rarely want to change them if you are not changing the interface anyways.
Backwards compatibility. Renaming a parameter is useful, for instance, when you extend an API to allow two different parameters where earlier only one was handled. For instance, a "Stdio.File file" changing into "Stdio.File|string file_or_filename" (or whichever order doesn't trig a compile error; I don't do that often enough to learn).
Spell fixes that also don't break backwards compatibility is of course nice. Granted, people have learned not to "fix" method names ("resolv" comes to mind) and could of course learn to let them remain in parameters too, but it's nice leaving the option there IMO.
pike-devel@lists.lysator.liu.se