Re: [TCLCORE] There is no justification for modifying [proc] for named parameters

I really think your counter-proposal is best, Alexandre.  It achieves the
stated goal, it trivially permits a parallel ::proc (I have been calling
::FAProc) and it imposes *nothing* on any part of Tcl.  It genuinely
improves Tcl, rather than putatively improving a single command.

I have repeatedly asked what justification exists for modifying ::proc over
the ::FAProc or ::eatargs counter-proposals.  None is forthcoming.

In my dark moments I fear that the reason the alternatives are resisted is
precisely because they renders this command putative-improvement optional,
and on some level its proponents understand that there are a slew of
packages available to do what they're proposing, and people don't use them
. and probably not because those implementations have substantial
overheads.

In my more forgiving moments, I consider it's just possible (particularly
in terms of the "like it or lump it" responses to suggestions) that the
authors have just fallen into myopic value-rigidity, having written
something at considerable expense to ape and extend ::proc, they are wedded
to the particular implementation choices they've made.  That's
understandable, it's human, I do it all the time.

There's another possibility, I don't know what to think about it, that the
::proc-mod has been commissioned - that it's a stated/explicit or even
implicit/dog-whistled requirement of the FA bounty.  I really don't know
what to think about that, if so.

Anyway, absent a justification, I can't help but speculate about what seems
to be an irrational decision.  I hope, though, my objections to it are
reasonable and not equally irrational.

Colin


On Sun, 21 May 2017 at 09:31 Alexandre Ferrieux <
alex...@gmail.com> wrote:

> On Sat, May 20, 2017 at 4:06 PM, Mathieu Lafon <mla...@gmail.com> wrote:> > Regarding the two proposals made by Alexandre :> >> > - Adding a new FAproc command will require to duplicate a lot of code> > already present in proc, leading to more maintenance. Users may find> > confusing to have a separate command and new users may not find it.>> I concur with Colin's answer to this: appropriate refactoring may> avoid any duplication. But never mind, as stated, this is not my> preferred choice.>> > - Adding a runtime handler seems to be limited to argument parsing,> > where the current proposal is a base framework which can be easily> > extended to later support other usecase on proc arguments (type> > assertion, doc-string, ...).>> Yes, and to me this lack of ambition is a bonus. Think KISS principle.> Do one thing at a time, and do it right. Don't open a Pandora box on> vague promises.> In this specific case:  type assertions and doc strings can quite> easily fit in handlers too, or in formatted comments at the top of the> proc's body.>> >  Unless I don't get the intent, it seems> > necessary to specify the named arguments when calling the command.> > Users may find counter-intuitive to have to specify the arguments in a> > second time (I assume proc only use 'args' in that case).>> Please give an example, I'm lost. You may even give a hefty list of> them, as an exercise for me to map to [eatargs] form :)>> -Alex>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot