RE: [TCLCORE] Re: CFV: TIPs #156 and #157

> miguel sofer <m...@utdt.edu> writes:> > In tcllib, every effort is done to provide code that runs > > conditionally on the tcl version and provides the new functionality > > toold interpreters.> > But the TIP doesn't specify any new functionality.  It only > specifies a new syntax for functionality that we already > have.  I don't see a need to complicate code by providing two > implementations, when one of the implementations (the old > one) works on all versions of Tcl and has no functional drawbacks.

Alright, this is where I step in to note how important this change is,
and to correct everyone's completely false assumption that the existing
eval hell has no functional drawbacks.  dgp asked me to post these
points that I made at Tcl2003 earlier, but I didn't think it necessary.
It obviously is.  It goes a little something like this:

Raise your hand if you think this is correct:

	eval entry $path $args

Everyone raising their hand please sit down.  You are wrong.  The $path
arg will be split apart as well, which is bad when using this in low
level code, like megawidgets or the like, where it must be handled
correctly.  After all, widgets with spaces in the names is 100% valid.

OK, so we know the fix, right?

	eval entry [list $path] $args

Ah, that's better ... but something is not right.  Hmmm ... oh, it is
inefficient!  The mix of list and string args will walk the wrong path
for optimization (this isn't important to everybody, but good low level
code writers should be sensitive to this).  OK, so that means this is
the best, right?

	eval [list entry $path] $args

Now I feel better.  What, that's not right?  If string args is actually
a multiline string, it won't work as expected.  Try it with:

	set args {
      	-opt1 val1
      	-opt2 val2
	}

and unfortunately that isn't theoretical.  I've seen code that uses a
$defaultArgs set up like that before regular args to handle defaults.

Ugh ... what are we left with?  This:

	eval [linsert $args 0 entry $path]

Only the final version is 100% correct, guaranteed not to blow when you
least want it to.

So we get back to the original point ... eval itself may not be
functionally flawed, but 99% of eval uses are.  In fact I don't always
use the final solution in code because it can get so unwieldly, but now
let me focus on tcllib, which was mentioned.  First let me say that my
favored solution is so much easier to use, has a minimal ugly factor,
and doesn't have any of the flaws above:

	entry $path {}$args

So on to tcllib.  I just grep the .tcl files for 'eval' and let me
pick a few:

# I sure hope critcl isn't in a dir with a space
./sak.tcl:        eval exec $critcl -force \
	-libdir [list $target] -pkg [list $pkg] $files

# Isn't this beautifully easy to understand?
./modules/ftp/ftp.tcl:        eval [concat $ftp(Output) {$s $msg $state}]

# I sure hope they don't use namespaces with spaces, or cmds ...
./modules/irc/irc.tcl:      eval [namespace current]::cmd-$cmd $args

# hmmm, just looks dangerous ...
./modules/struct/record.tcl:    eval Create $def ${inst_}.${inst} \
						[lindex $args $cnt_plus]

# I'm not sure why eval was used here.
# I think because version can be empty?
./modules/stooop/mkpkgidx.tcl:  eval package require $name $version

# I think someone needs to look up 'concat'
./modules/textutil/adjust.tcl:  lappend list [ eval list $i $words($i) 1 ]

OK ... so I'm tired of looking now.

  Jeff Hobbs                     The Tcl Guy
  Senior Developer               http://www.ActiveState.com/
        Tcl Support and Productivity Solutions



-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
_______________________________________________
Tcl-Core mailing list
Tcl-...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tcl-core