Re: [TCLCORE] Tcl 9 Wart Removal List, Rev. 1

[Karl L. <kar...@gm...>]

On Nov 19, 2012, at 1:00 PM, Andreas Kupries <and...@ac...> wrote:
> 
>> Automagic stdin/stdout/stderr reincarnation
>> Per Joe English, this should be removed.  (Why?  What is it?)
> 
> This is Tcl's magic where if you close stdout, for example, the next
> opened channel becomes the new stdout. Ditto for stderr and stdin.

This is standard UNIX behavior.  It's handy.  For those of us who do fork in Tcl using TclX it lets you code the fork parent/child handling as you might in C.   If there's something compellingly bad or problematic about it then I could probably go for getting rid of it but if it's merely disgust then I would ask to keep it.

>> [file stat]
>> Per Joe English: "I think the Tcl API is also a candidate for replacement.
>> All but two of the fields returned are are Unix-specific, this interface has
>> no place in a VFS world."
> 
> I think I used the uid/gid information in some code to detect when a
> file/dir traversal reached a file a second time (symlink loops). Today
> I would use 'file normalize' instead to get a canonical path and
> hash/check on that.
> 
> ... I have trouble coming up with use cases for it …

We've got code that uses it a fair amount but again it's sort of a performance hack from the old days insofar as I recall the reason it exists is to be able to get all those "struct stat" fields without invoking the stat call multiple times as you effectively would if you had to do "file atime", "file mtime", etc.  Not so important anymore...

> 
>> [glob -nocomplain]
>> Never complain; the caller can check the result in the cases where it
>> matters.  We might wish to allow "-nocomplain" as allowable but deprecated
>> syntax for a time.
> 
> Agreed.

I'm there.

>> ::env() array
>> Per Joe English and others, the current behavior of this array is
>> unavoidably thread-unsafe.  We need some way to access environment variable
>> values, though, so some other mechanism would have to be defined.  An [env]
>> command, perhaps?

"env get", "env set", and "env unset"?

>> [pkg_mkIndex]
>> The standard best practice these days is to write pkgIndex.tcl files by hand
>> (or, possibly, to use Tcl Modules).  [pkg_mkIndex] is a bright idea that
>> didn't pan out, and should be removed.
> 
> Agreed.

Eh we use it still but if people want to get rid of it it's ok with me.

> 
>> [unload]
>> Per Joe English, this should be removed.  Reasons?
> 
> Complexity of unloading a shared library cleanly (dangling pointer,
> and other badness, if the writer of the shlib is not careful, and
> impossibility of avoiding the badness in some cases).

Yeah unloading shared libraries is pretty problematic.  While we will forget and re-require Tcl packages in running programs, if we want to change out a shared library we restart it.

> 
>> [unset -nocomplain]
>> Never complain; the caller can use [info exists] to see if the variable
>> exists in the cases where that matters.  We might wish to allow
>> "-nocomplain" as allowable but deprecated syntax for a time.
> 
> Agreed (both proposals).


I agree as well and while I find it kind of appealing to get rid of "-nocomplain", it would one of the bigger breakers of old programs for a minuscule payoff.  I think deprecate "-nocomplain" with a policy for when it will be removed, like "after two years" or "in 9.2".