From: Mathieu L. <ml...@gm...> - 2017-01-17 22:19:08
|
Hello Brian, On Tue, Jan 17, 2017 at 1:54 AM, Brian Griffin <bri...@ea...> wrote: > I noticed one typo in the TIP, see "wich" here: Fixed, thanks. > Some points on reviewing the TIP: > * The proposal is straight forward so I wouldn't imagine the implementation to be overly complicated. > * It seems somewhat limited to have this feature only apply to proc's without a corresponding extension to the C API for providing the same compatibility for non-proc commands. Users of [call] may find it confusing to have it work with some commands and not others since it's not immediately obvious which commands are implement as procs and which are implemented in C. It is easy to add a way for non-proc commands to define argument names and default values and be able to be called by [call]. But it's not possible to automatically handle non-proc commands for which we do not have arguments definition. This may be even more confusing if some non-proc commands can be used and the others can't. Do you think it should still be added? > * It should be made clear that [call] is not [eval]. If it is, then that's an whole other can of worms. Right. I have added a note in the TIP and will also add one in the command documentation. > * Unfortunately, [call] is too generic. We happen to have a [call] command in our application already. I wouldn't be surprised if there where collisions in other applications. It might be necessary to make the command hideously unique, e.g., tcl::call, callproc, call-by-name, ... I'm open to suggestions regarding the command name and will use the most appropriate one once a consensus is found. Regards. -- Mathieu |