| Store | Cart

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

From: Mathieu Lafon <mla...@gmail.com>
Wed, 18 Jan 2017 22:32:42 +0100
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
Recent Messages in this Thread
Peter da Silva Jan 18, 2017 04:17 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 05:20 pm
Peter da Silva Jan 18, 2017 05:32 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 06:08 pm
Mathieu Lafon Jan 18, 2017 09:32 pm
Peter da Silva Jan 18, 2017 10:25 pm
Mathieu Lafon Jan 18, 2017 11:07 pm
Dipl. Ing. Sergey G. Brester Jan 18, 2017 11:49 pm
Peter da Silva Jan 18, 2017 11:52 pm
rene Jan 25, 2017 10:15 am
Steve Landers Jan 25, 2017 12:06 pm
Gustaf Neumann Jan 25, 2017 01:50 pm
Peter da Silva Jan 25, 2017 01:55 pm
rene Jan 25, 2017 02:00 pm
Peter da Silva Jan 25, 2017 04:11 pm
Florent Merlet Jan 25, 2017 08:20 pm
Messages in this thread