Re: [TCLCORE] Tcl 9 Wart Removal List

[Porter, D. <don...@ni...>]

The function of loading (the true definition of) a command on demand is still
useful in some situations.  What's out of date is expecting Tcl's default [unknown]
command to do the task for you.  It's far easier, and independently robust to
build your on "on-demand-load" stubs to get the task done.

namespave eval my {
    variable home ;# set when package/app is loaded/initialized

proc foo {args} {
    variable home
    source [file join $home foo.tcl] ;# File with real [my::foo] command.
    tailcall foo {*}$args ;# or similar [uplevel] games
}
} ;# end namepsace eval my

If you have more than one, it's quite a simple exercise to build them all like
this with a suitable loop over a dict or array mapping commands to defining
files.  With clear variants when a [load] rather than a [source] is called for.

Now the first call to [my::foo] auto-loads the real definition on demand, every
bit as well as Tcl's auto-load mechanism with no ugly tclIndex file with its
global namespace pollution, or confusing
contention over ::auto_path between [unknown] and the package finder, or
struggles with incapable [auto_mkIndex] tools, or head scratches over
[namespace which] failures to find my::foo even though you "know" it's
part of the package, because with this better loading mechanism the command
does really exist even before the loading is triggered.

________________________________________
I for one use auto_load in large libraries where user can use only some parts.
I even have a complete application delivered in a .tm, which can be integrated in other applications, which allow using only some components while replacing the main GUI.
What mechanism can replace auto_load? (splitting it in a myriad of packages is not a solution in this case).