[TCLCORE] CFV: TIP #414: Add (back) Tcl_InitSubsystems as Public API

[Jan N. <nij...@us...>]

2013/6/13 Jan Nijtmans <jan...@gm...>:
> 2013/6/13 Donald G Porter <don...@ni...>:
>> A routine that changes return type on compiler directives?
>>
>> And this is the "simple, no controversy, rush it through, nothing to
>> see here" proposal?
>>
>> Um no.
>
> Would you be more comfortable with:
>      <http://core.tcl.tk/tcl/info/085d8ad9a1>

Even though Joe answered my question, it was really meant
for Donald. Let's look at the current status.

There are so far 3 YES votes, mine, Alex's and Brian's. There
is a PRESENT vote from Donal. There is a NO vote from Donald,
which only concerns the TIP implementation, not the text of
the TIP (@Donald, please correct me if I'm wrong here).

And there was a Present vote from Joe, later changed to a
NO because of the same implementation concern. So for
the TIP to have any hope at all, the implementation has to
change, which I did now in:
      <http://core.tcl.tk/tcl/info/77799a9144>
The wording of the TIP is not changed at all. The TIP #0
process specifies voting to occur on the specification on
the TIP, even though the implementation only can go
in after approval from the maintainer.

The reason for the original implementation was an attempt
to re-use the function Tcl_InitStubs() to do the actual
stub table initialization. This funcion has a Tcl_Interp
as input parameter, which was mis-used for this purpose.
This weekend I found a just as good alternative: a new
internal function TclInitStubTable(), which does part
of Tcl_InitStubs(), just the part needed here.

@Donald, @Joe, is this implementation alternative reason
to change your vote? Or maybe even for Donal to change
the PRESENT to YES  ;-). If so, that would help going
forward with this TIP's. Of course, if there are other
concerns those should be discussed as well, but
Alex, Brian and I already did that extensively, which
can be read in the mail archives. I'm not trying to
rush this in without proper evaluation. But I think
that the TIP and the implementation now fulfill
all requirements as discussed before, so I don't
see a reason to wait.

For people interested, here's a short summary of the
requirements discussed:
The function Tcl_InitSubsystems() should be
usable:
    A) without actually creating a Tcl interpreter (Brian)
    B) without initializing encodings (Brian)
    C) without [info nameofexecutable] (Brian)
    D) when using embedding (me)
    E) when using stubs (me)
    F) when using a custom panicProc (me)
    G) when using VFS (Alex)
    H) with or without using Tcl_Main (Donald)

Brian's original TIP #414 only handled A), B) and C). My later
revisions added D) E) and F), but broke G). In the discussion
that arose it was agreed that this TIP should only handle
the first function in the initialization sequence. So, G) and
H) will be handled in a future TIP, nothing in the current
TIP prevents this being done correctly. This means there
are 6 on/off switches, Tcl_InitSubsystems() should be
usable in all 64 possible combinations. Of course, many
people only need a subset of those (I don't use
Tcl without a Tcl interpreter, but I am using embedding
with stubs with a custom panicProc).

@Donald, @Joe, would this changed implementation
change your vote? Should the vote period be extended?

Regards,
         Jan Nijtmans