Multiple inclusion of source files can be avoided in compiled
programming languages like C++ by preprocessor
statements.
...
#if
!defined(_my_text_included)
#include
"my_text.h"
#endif
...
The TCL function
"source" includes files, too. But there are no preprocessor
directives in a scripting language like TCL. Their statements get
executed every time.
The language PHP provides the
function "http://de.php.net/manual/en/function.include-
once.php".
I suggest to add the option "-once" to avoid
multiple inclusions of TCL code.
...
if
{_my_text_included == 0} \
{
source "my_text.h"
}
...
# Write just one line to achieve the same as before
with more safety
source -once "my_text.h"
Logged In: YES
user_id=79902
I'd suggest using packages instead, and [package require]
works a bit like [source -once] would except it uses a
slightly more abstract notion (package name) and works with
things other than single Tcl script files.
dgp: Please reopen if you disagree.
Logged In: YES
user_id=572001
I do not want to create a package for every file that needs to be inluded
once.
I think that is to much work.
Logged In: YES
user_id=80530
Perhaps auto-loading is a
more attractive alternative
for you?
http://wiki.tcl.tk/tclindex
Either auto-loading or packages
is the right answer. Adding this
kind of magic to [source] is
not a good idea.
Logged In: YES
user_id=572001
Sorry - I've got an opposite opnion.
"...
Auto
Loading
If you're building a library of tcl scripts, you should
consider using utilizing one of Tcl's auto-loading
mechanisms.
..."
I do not want to build a library.
I do
not think that a function [source -once $file] is "magic". It may be seen a
little bit as a convenience feature. But it can provide more speed and
safety.
Logged In: YES
user_id=80530
OK, let me try putting is a different
way then.
[source] is, and should remain, a
fairly primitive operation. The kind
of one-time loading constraint is
better implemented as a higher level
routine that calls on [source] just to
do the sourcing work, and maintains
its own store of already sourced
file names to avoid duplication.
This can be achieved in a [proc]
of less than 20 lines, so I don't see
any need for changes to the core
interface.
When writing that [proc], consider
applying [file normalize] to the file
names before storing.
Logged In: YES
user_id=572001
I understand your intention now.
How do you think about to
create a new command [include $file] that implements the "one-time
loading constraint"?
Can these "20 lines" be added to the standard
TCL function library so that all the developers do not need to write
several versions for it on their own?
Logged In: YES
user_id=79902
Given that neither dgp nor myself feel very happy about
adding this feature, please could you tell us a bit more
about a specific situation where this would be useful but
existing solutions (based upon the package mechanism and
autoloading) do not satisfy. I've had a think about this,
and all I can really think of is some kind of (possibly
per-application) library, which is already covered by the
features already listed.
Logged In: YES
user_id=572001
1. The autoloading mechanism depends on the variable "auto_path". I
see it as a system setting over which I have not the control all the
time.
- http://mini.net/tcl/1628
-
http://tcl.tk/man/tcl8.4/TclCmd/tclvars.htm
2. The
package mechanism needs even more configuration.
3. A new
function [include $file] can give developers that are used to
programming languages like PHP an easier way to source TCL code.
Logged In: YES
user_id=572001
4. It seems that this request runs into a discussion about the topic to do
things the TCL way.
5. How do you think about a little "hack" that
a developer creates a package that contains the requested function
"include"?
It will be a normal extension in this case.
Logged In: YES
user_id=79902
1.If your apps can't control their variables, they're in
trouble. Seriously. And libraries should not be altering
::auto_path under normal circumstances. (I'm not convinced
that you've got non-normal circumstances here.)
2.If you're building a library, use the facilities provided.
They're tested and maintained.
3.I thought the PHP mechanism was for script libraries. But
then where I work PHP is something of a byword for security
holes.
4.Too right, and you have two people saying this isn't the
Tcl Way
5.You can do *anything* you want in your own code. It's yours.
Still waiting for that killer use-case.
Logged In: YES
user_id=572001
1. I want to leave the system variable "auto_path" untouched.
A
release note for the package "http://oratcl.sourceforge.net/" talks
about "auto_path idiosyncracies".
2. I know. The descriptions
"http://www.tcl.tk/doc/tea/" look like too much work for some
situations.
3. PHP developers know the functions
"require_once" and "include_once". The requested comfort is
provided by PHP.
It can be added to TCL with the same name. You
have got the opinion that this should not belong to the core library so
far.
4. I am trying to introduce a topic that I do not see
"tclish".
5. The command [package require $extension] is the
only function that avoids multiple inclusions at the moment.
If a
new package cannot be build because of administration
circumstances, you must look for other safe ways to include a small file
collection.
Am I the only one that is interested in this little
enhancement?
Logged In: YES
user_id=113501
This type of functionality does not need to be included in the
core to be useful.
proc sourceOnce { file } {
upvar "1" sources sources
if {![info exists sources([file normalize $file])]} then {
# don't catch errors, since that may indicate
# we failed to load it...?
uplevel "1" [list source $file]
# mark it as loaded since it was source'd with no error...
set sources([file normalize $file]) "1"
}
}
Logged In: YES
user_id=80530
I'm referring further discussion
on development of such a
utility command to the wiki.
http://wiki.tcl.tk/source
There's no longer a feature
request for Tcl here. Best next
step is to create the command
(see wiki) and use it for yourself.
Offer it to others. If it's useful
and popular, it will find a home
in a widely used package (maybe
distributed in tcllib or ActiveTcl?)