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

On Sat, 20 May 2017, 23:36 Mathieu Lafon, <mla...@gmail.com> wrote:

> Colin,>> My intent was not to denigrate your analysis but to try to calm things> down. Sorry for having triggered the opposite...>> We have a disagreement on how this should have been implemented. I> have chosen to modify proc argument specifiers after having proposed> other options (including a dedicated command to call a proc :> http://www.tcl.tk/cgi-bin/tct/tip/view/457?ver=1.7) and received> feedback in that way. The initial FA bounty description was requiring> that it must work with unmodified proc, so the spirit of the bounty> seems to favor keeping proc and not adding a separate command.>

I am blissfully unaware of the orifinal terms of the bounty, but as I read
it now there is absolutely no requirement that proc be modified.

I am also really dismayed that one might be able to bid for mods to core
commands.

Having chosen to modify proc, this implies impact on code, performance
> and documentation, which I have tried to keep minimal, but are> inherent to that decision. I have carefully ensured that the new code> is well separated so that it is easy to review and maintain and that> the proc not using extended specifiers are not impacted in any way.>

I have no reason to cast aspersions on your code.  I merely seek to
criticise your quite arbitrary choice to modify proc to insert
functionality like this.


> 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 don't believe code is ever required to be duplicated.  Refactoring proc
so as to expose an interface which FAproc can use would always be an option.

- 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, ...).


Since the proposal was, I believe, to implement named arguments, I can well
understand why one would expect it to be limited to argument handling.

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).>

It sould be possible (I think trivial) to use such a handler to implement
FAProc in all its glory and wonder, however it's conceived or the concept
evolves.

I don't have any strong positions on any alternate proposal, I only
> want to give my current proposal a chance to be considered.>

Well, I considered it, and I think changing proc so its resultant command
no longer resembles those of apply, namespace ensemble, interp, coroutine
etc is a great mistake.

Colin


> -- Mathieu>>> On Sat, May 20, 2017 at 12:41 PM, Colin McCormack <mcc...@gmail.com>> wrote:> > Excuse me, Mathieu, but I'm not simply "against it."> >> > I have raised what I consider to be cogent criticisms of a proposed> course> > of action, and as far as I can tell you have addressed none of them.  I> > sought to understand why our opinions differ about what is best.> >> > To denigrate my analysis as 'flaming' doesn't discredit it, and to fail> to> > meaningfully engage with it surely only undermines your proposal.> >> > I believe that you have misread the bounty's stated requirements, if you> > believe that modifying [proc] is essential to satisfying them.> >> > Whence did the idea arise that distorting proc was the best way to add> the> > functionality you appear to desire, or desire to implement?> >> > Colin> >> >> > On Sat, 20 May 2017, 20:02 Mathieu Lafon, <mla...@gmail.com> wrote:> >>> >> I don't want to enter a flame-war with you. I understand that you're> >> against it and I completely respect your point of view but I don't> >> think I will change your mind.> >>> >> I admit that I have failed to reach a consensus but please respect the> >> work done and the opinion of the people who have supported the work.> >>> >> -- Mathieu>

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