Suspicious design around the max length of method names and max count of method parameters

[xiaoxiao921]

I have to interop with legacy C code that have some functions which have their names longer than 64 characters and have sometimes more than 16 parameters. if one of the main use cases for such projects is to interop with some parent hosting language code, why was the limit not equal to that parent language?

[mhermier]

Because 64 characters and 16 parameters should be enough for most use cases, and having more than this "should" be considered a bad practice. So wanting to reach the 4k characters limit or 127 arguments limits of C is futile.

From my point of view the interoperability is never a main use case, but more an unfortunate requirement. I mean no sane language implementation wants you to escape from their computational model, so implementors can't reason about what is going on. Having an interruption (of any form) in the language to do interoperability with some host bindings, is always a source of fragility.

For your specific use case, there is some possibility to mitigate the issue to some extents:

• The 64 characters name limit can be easily be increased by modifying: https://github.com/wren-lang/wren/blob/c2a75f1eaf9b1ba1245d7533a723360863fb012d/src/vm/wren_common.h#L88-L91

• The 16 parameters limits, there is some room to add some direct CALL opcodes in the VM: https://github.com/wren-lang/wren/blob/c2a75f1eaf9b1ba1245d7533a723360863fb012d/src/vm/wren_common.h#L83-L86 https://github.com/wren-lang/wren/blob/c2a75f1eaf9b1ba1245d7533a723360863fb012d/src/vm/wren_opcodes.h#L80-L118 https://github.com/wren-lang/wren/blob/c2a75f1eaf9b1ba1245d7533a723360863fb012d/src/vm/wren_vm.c#L982-L1024 The other solution being to add a 2 byte opcode, that encode the number of arguments in the second byte. (My preferred solution since they should be quite rare, unless it is proven to become a performance issue)

[mwasplund]

I was also very surprised by this when porting over some code. I have large container classes that move a large number of function parameters into a single class for easy passing around a lot of options and the constructor should contain all the values so I can make the struct read only.

If there is no physical/performance reason for this limitation I would prefer if it was removed. Simply having a limit because it is a bad practice is not a good reason because there are always exceptions to the rule. At a minimum this limitation should be well documented so it is not a surprise to new users.

[PureFox48]

I can't say I've ever found these limitations a problem but a possible workaround would be to pack all parameters after the 15th into a Wren map or list.

You can then unpack them from the host and call your constructor normally.