Re: [TCLCORE] Delaying CVF#340 until dec 5 (Re: CFV TIP #340)

[Joe E. <jen...@fl...>]

Jan Nijtmans wrote:

> Here is the results of TIP #340 vote (Provided I
> interpreterd JE's correctly.
>
> JN: YES
> JE: NO
>
> This means the TIP is rejected.
>
> The best guess about the why question is Kevin's remark:

Erm...

For my part, this is the main reason:

| jenglish@eurydice$ folder
| inbox+ has 283 messages  (1-425); cur=377.

I saw the note mentioning that the TIP had been updated,
took a quick look, saw an ABSTRACT section and and a
RATIONALE section but no SPECIFICATION; thought "OK,
it'll take some effort to figure out *exactly* what's
being voted on, will get to it later", and have not
gotten around to doing so yet.

Sorry about that.  It's just that:

| jenglish@eurydice$ folder
| inbox+ has 283 messages  (1-425); cur=377.

For what it's worth, I would vote YES on the following:


| SPECIFICATION
|
| Add a new convenience routine to the public API:
|
|	void Tcl_SetStringResult(Tcl_Interp *interp, const char *result);
|
| which shall be equivalent to
|
|	Tcl_SetObjResult(interp, Tcl_NewStringObj(result, -1));
|
| The existing routine Tcl_SetResult() shall be formally deprecated.
|
| END SPECIFICATION.


> Kevin Kenny wrote:
> > I don't think there's any controversy that
> > we want to kill Tcl_SetResult -- eventually. It isn't const-
> > correct, and can't be made const-correct. But, aside from
> > spewing compiler warnings, it's Mostly Harmless. The chief
> > reason for wanting to kill it is that it's all tied up in
> > the manipulations of interp->result, and we have to wait at
> > least another release cycle before we can put paid to them.

I don't think that's exactly right -- Jan and I have identified
a path towards eliminating interp->result internal manipulations,
and I don't think it needs to wait a complete release cycle (all
of the changes are internal and could be done at any time).
Tcl_SetStringResult() would help smooth the path is all.



--Joe English

  jen...@fl...