A lot of effort is often put into making things ''backwards compatible'', i.e. making sure that a change in a new Tcl release does not break old code.

This page is about the opposite: writing extra code so new functionality can be used in older versions (of Tcl and Tk, in this context).

An example of this is [glob forwards compatibility].  The code on that page is about the new ''glob -dir path *'' idiom which was introduced in Tcl 8.3.  A useful change, and there are so many more like it.  The trouble is, once you start using it in your own scripts, you cut off the ability to use those scripts in pre-8.3 Tcl.

One way to get around this is to use conditional code, of the form "if I'm running under Tcl 8.3 or later, do <this>, else do <that>".  But that may well defeat the purpose: imagine doing this to use the new "array unset" that way: it might well end up more confusing than a simple info/array condition + action.

That's where ''forward compatibility'' comes in: at the start of your app, check what version of Tcl is running, then load a bunch of extra definitions and overrides, which emulate the new features in scripts which call the available (lesser) features.

Forward compatibility is '''Important'''.  Forward compatibility is '''Good'''.

There are plenty of little features which can simplify scripts just a tad more (unset without complaining, file attr changes, glob, info, not to mention Tk changes), but which I have to avoid simply because the consequence of using would have the major implication of forcing a new revision (and compile/configuration hell) onto the people using my code.  That is often not justifiable: ''You want me to fetch Tcl/Tk N+1, figure out the build again, install it again, and introduce the potential of version conflicts or at least dependencies, '''just''' so you can use "array unset"? Yah, right.''.

The irony of writing lots of extra snippets of code to implement forward compatibility is that - in the end - it promotes the adoption of newer versions of Tcl/Tk and new features.

So here's a suggestion: the next time you write an "if Tcl version < N" in your code, how about writing a '''forward-compatibility snippet''' instead, and submitting it on this wiki?  Just a thought... --jcw

----
The [OOMMF] project has done a lot of this.  Examples below.
'''DGP'''

See also [Changes in Tcl/Tk] for a source of things which can be done.

----
Here's a start:
   * [glob forwards compatibility]
   * [file forward compatibility]
   * [grid forward compatibility]
   * [clock forward compatibility]
   * [fcopy forward compatibility]
   * [destroy forward compatibility]
   * [menu forward compatibility]
   * [string forward compatibility]
   * [lindex forward compatibility]
   * [lmap forward compatibility]
   * [lset forward compatibility]
   * [forward-compatible dict]
   * [lreverse]
   * [http://wiki.tcl.tk/lassign#pagetocaa2ba245%|%forward-compatible lassign]
   * [Forward-compatible try and throw]
   * [Forward-compatible tcl::prefix]
   * [Forward-compatible lsort]
   * [http://wiki.tcl.tk/dict+map##pagetocbd00762e%|%Forward-compatible dict map]
   * ...

Note that most of the above could be improved by using
a utility procedure for [wrapping commands].

----
Seems to me that these are good candidates for [Tcllib]! Some like [try] and [throw] are already there.
In the mean time, I am collecting some of these into a https://github.com/efrecon/til/tree/master/compatibility%|%module%|% of the [TIL]. If TIL is properly installed, accessing some of those commands from older versions of Tcl only requires `package require compatibility`. This will work starting with 8.4 and fully on 8.5. [EF]

----
Note this can be done in Tcl's  C code too:
   * [Tcl_GetStringResult() forward compatibility]
   * [Tcl_GetChannelHandle() forward compatibility]
   * [Tcl_PkgPresent() forward compatibility]
   * [Tcl_SaveResult() forward compatibility]
   * [Tk_SafeInit() forward compatibility]
   * [Tcl_GetErrorLine() forward compatibility]
   * ...

----
Are there other list functions which need a forward compatibility wrapper?

[KMG] 04-Sep-05 Added ''lindex'' to the list above for the new multiple-index feature in 8.4.

<<categories>> Porting