Builtin functions refactoring #169
Conversation
FLHerne
force-pushed the
FLHerne:flh-builtins-cleanup
branch
3 times, most recently
from
2c9dae2
to
008efe0
|
Not a huge fan of the "random" distinction between I'd probably go with always having a "builtin_" prefix to the function name and always using |
| @@ -562,8 +562,7 @@ def industry_town_count(name, args, pos, info): | |||
| return (args[0], extra_params) | |||
|
|
|||
| def industry_cargotype(name, args, pos, info): | |||
| from nml.expression.functioncall import builtin_cargotype | |||
| return (builtin_cargotype(name, args, pos), []) | |||
| return (expression.functioncall.builtin_resolve_typelabel(name, args, pos), []) | |||
frosch123
Dec 4, 2020
Member
builtin_resolve_typelabel would not need that "default to cargo" trick, if there was a 4th optional paramater for the function name, like
builtin_resolve_typelabel("cargo", args, pos, username=name)
builtin_resolve_typelabel would not need that "default to cargo" trick, if there was a 4th optional paramater for the function name, like
builtin_resolve_typelabel("cargo", args, pos, username=name)
FLHerne
Dec 5, 2020
Author
Contributor
I really don't like this idea. The existing name parameter already has that meaning; passing in a fake value to manipulate the behaviour and then adding a new parameter for the real value seems like a far bigger hack. The default is going to exist somewhere, why not here?
(I updated the comment a bit)
I really don't like this idea. The existing name parameter already has that meaning; passing in a fake value to manipulate the behaviour and then adding a new parameter for the real value seems like a far bigger hack. The default is going to exist somewhere, why not here?
(I updated the comment a bit)
I changed |
Yay, more random cleanups.
Slightly RFC on the decorator bit; if this style makes sense there are probably more things to apply it to. Personally I think anything is better than these big tables.