Re: [TCLCORE] TIP #457 - Named Parameters Implementation

Karl should have responded earlier, I agree. He apologizes for that, and I (as a loyal minion) am picking this up now.

The intent here is that this be something that is convenient and natural so it actually gets used. Adding an additional wrapper command for the caller is undesirable because we feel it discourages actual use. As something to use as a placeholder during development, “call” or “something is fine, but at the end it needs to be syntax.

Being able to rearrange the calling sequence so that you can put named optional parameters before positional parameters, that might be nice, but it’s not something that’s likely to come up… particularly with existing commands. I get the impression from the message you linked that’s a large part of the motivation for the complexity of the “call –nargs/-opts” syntax, am I correct?

So. Regarding the conflict with existing procs, I did acknowledge and sort of address that by noting that this would only be used where a proc with the extended name did not already exist, and also proposed an alternate {-} sentinel that could not conflict.

In any case, this specific “-proc” syntax is not a requirement, but something comparable that makes the named variable syntax feel native and work in contexts where a proc or command is expected is strongly preferred. 

I talked with Karl some more, and he’s not totally married to being able to automatically use any existing proc or command with named parameters, just almost, and he’s convinced it should be possible for procs without adding complexity to the proc declaration.

On 1/18/17, 3:32 PM, "Mathieu Lafon" <mla...@gmail.com> wrote:

    Hello Peter,
    
    On Wed, Jan 18, 2017 at 5:17 PM, Peter da Silva
    <pete...@flightaware.com> wrote:
    
    > I’ve been discussing the TIP #457 with Karl, and it seems to be taking> things in a direction that doesn’t really address the intent of the> FlightAware Tcl Bounty.
    
    Thanks for your feedback. I'm open for inputs by the Tcl community and
    FlightAware to be able to define the most appropriate solution for
    this use case. I understand you are not happy with my current
    proposal. I just want to note that I have made several proposals and
    tried to reach a consensus among the received feedback, suggestions
    and critics. This may not be perfect and I will continue to work on
    it.
    
    > [...]> 1. There's really no need for a huge amount of flexibility in the "new> syntax". Either existing positional style, or the new named style using the> information provided in the proc definition, are the only alternatives> needed. Extensions like the one implied by "call -opts -npos 1"  are really> kind of overkill.
    
    The -npos option is optional, so most users will only use "call -opts
    ...". This option was added after a comment
    (../tcl-core/16638/) that this may be
    important to have. But you're right that this may be too much if it is
    the most use case.
    
    > 2. On the other hand, some kind of flag on the call of a proc is ok, and is> probably required, but it needs to be something that doesn't create a heavy> cognitive load on the caller.>> [...]>> So, by point 2, let's say we have a flag on the call or any proc: if the> proc name is preceded by a "-" and the same proc name with the "dash"> included doesn't already exist, then the call will be made with the named> parameter syntax:
    
    What if we keep a builtin command which *defaults* to using options.
    Let's keep the name 'call' for the command but this will probably need
    to be changed. For example:
    
    [call foo zot b] -> "called foo bar= zot opt1= {} opt2= {} args= b"
    
    Other options (npos, noopts) may be available for users with specific
    needs but most users will use it without any parameters.
    
    Is this something which can match your expectations or do you think a
    specific calling convention is most appropriate?
    
    Regarding using a dash before the proc name, note that it is currently
    possible to define a proc starting with a "-", so we're not completely
    sure of not breaking existing (bad) code. Same with '@' and '*'.
    
    > 3. Finally, and importantly, there's really already enough information> provided in existing proc definitions to unambiguously define a viable new> behavior for any proc that currently uses optional positional parameters.>> [...]>> In addition, it would be OK to have something to flag a proc as always> taking the new syntax. For example:
    
    This can be easily added but will perhaps confuse users as they will
    have to deal with two ways of calling a proc. Is this something
    important for you? Note that it was not specified in the bounty
    request.
    
    Regards.
    
    -- Mathieu
    

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core