>
> ------------> 48 occurrences of deprecated commands in documentation
>
> so, cleanup item 6 is
>
> 6) documentation should not be based on deprecated commands
>
The mentioned issues are fixed.
Here is the summary of the current state of the cleanup:
Tested commands
------------> 709 tested commands, 86 deprecated, 639 documented, 0 NOT
documented
------------> 0 usage message differ from doc, 639 are identical
Documented commands
------------> 639 documented commands, 639 tested, 0 NOT tested
Deprecated commands
------------> 0 deprecated commands are documented
------------> 0 occurrences of deprecated commands in documentation
------------> 38 deprecated commands are tested
C-implemented commands:
C-implemented command is not documented: _ns_adp_include
C-implemented command is not documented: exit
C-implemented command is not documented: chilled
C-implemented command is not documented: keylget
C-implemented command is not documented: keylkeys
C-implemented command is not documented: keylset
C-implemented command is not documented: ns_crash
The statistics refer just to the commands starting with “ns” to leave out some
of the internals, which are not too many.
We have 6 C implemented commands not starting with the usual NaviServer prefix,
and one command which was intentionally not documented:
- I will document “ns_crash”, If no one objects.
- the keyl* commands are inherited from TclX. From my point of view, there is
little reason to use in new programs, since it resembles in essence the Tcl
“dict” functionality with a different syntax.
(correct me, if I'm wrong am wrong).
I see the following options
* deprecate it
* put it into a separate module
* drop it, since tclx is still maintained by flightaware
(https://github.com/flightaware/tclx/), so people can load it via “package
require”.
I am in favor of deprecating it in NaviServer 5, such that users get warned
about its usage.
- _ns_adp_include: In my understanding, the only reason for having a command
“ns_adp_include” and a separate command “_ns_adp_include” is the proc
call-frame on the top-level to keep local variables. It should be possible to
create this call-frame via the public API of Tcl. I will look into this.
As always, feedback is welcome.
-g
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel