I don't think I'll say anything new in this message for those who want
to skip now.

Thanks for raising the topic of TIP 178 prior to calling for a vote.
When that vote is called, I plan to vote NO.  I'm posting this message
just to restate my reasons why, and so there'll be no unpleasant surprise
when my vote is cast.

TIP 178 proposes a new [info pid] subcommand to be equivalent to (a
subset of?) the existing [pid] command (but explicitly not a possibly
extended [pid] ensemble).  It also proposes a new [info tid] subcommand
to be equivalent to the existing [thread::id] command of the Thread
package.  Some observations,

1) [pid] exists.
2) When threads are enabled, the Thread package and [thread::id] exists.
3) [info] is an ensemble.

So, TIP 178 does not add any functionality to a thread-enabled interp.
It is entirely about command name beautification.  Such beautification
is already available to the scripter via the [namespace ensemble]
ability to add subcommands.  So, this TIP adds nothing to capabilities
of the public interface of a thread-enabled Tcl that's not already there.
Its only justification would be that the beauty of [info pid] and
[info tid] over [pid] and [thread::id] is so compelling we want to
provide it as the default.

[info] is already ugly.  I've ranted about this before, but can't
locate it at the moment.  Current trends are away from dumping more
into the incoherent mess of [info].  They are toward offering better
alternatives outside of [info].  Use [package present Tcl], not
[info patchlevel].  Use [namespace which], not [info commands].

In the context of [lsearch], we've fallen into an acceptance of
"Yeah, it's ugly, so a bit more ugliness can't really hurt."  But
those proposals actually add functionality.  In contrast, TIP 178
is solely about adding ugliness while claiming to add beauty.

When threads are not enabled, things are worse.  On exactly those
platforms where --disable-threads builds are still normally the default,
Tcl_GetCurrentThread() returns the meaningless value of 0, and TIP 178
remains silent about what [info tid] should do in that case.

All that said, I am *not* asking that a vote be delayed on this.  If
there's still no intent to address these problems first raised 3+
years ago, then please hold the vote, so I can vote NO and I can either
win or lose and we can move on.

-- 
| Don Porter          Mathematical and Computational Sciences Division |
| donald.porter@[...].gov             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference 
Don't miss this year's exciting event. There's still time to save $100. 
Use priority code J8TL2D2. 
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core