A suggestion for handling modifications in the core that change the script API 
Author Message
 A suggestion for handling modifications in the core that change the script API

Hi,

recently there were several discussions on c.l.t about changes in the
Tcl core which would clean up the script language but break old
scripts, e.g.

- change all the "lxxx" commands to "list xxx"
- change the name of the "array" command
- change the behaviour of "unset" for non-existing variables
- ...

I suggest to provide the old script API and behaviour by default and
change it at runtime as a side effect of "package require". If a
script wants to use a newer API it has to call

        package require Tcl $some_newer_version

in order to get the API of that version. So every script will get the
API of that version of Tcl it was intended to run on even if it runs
on a new interpreter that introduced some incompatible changes. This
will carry on the backwards compatibility that stubs provide for the C
API to the script level.

Retaining the old APIs should be a compile time option so one can get
rid of the old stuff if he knows that he never has to run old scripts.

Any comments are welcome.

cu
        Reinhard
--
If you put garbage in a computer  nothing comes out but  garbage.
But this garbage, having passed through a very expensive machine,
is somehow enobled and none dare criticize it.



Fri, 08 Nov 2002 03:00:00 GMT  
 A suggestion for handling modifications in the core that change the script API

Quote:

> recently there were several discussions on c.l.t about changes in the
> Tcl core which would clean up the script language but break old
> scripts, e.g.

> - change all the "lxxx" commands to "list xxx"
> - change the name of the "array" command
> - change the behaviour of "unset" for non-existing variables
> - ...

> I suggest to provide the old script API and behaviour by default and
> change it at runtime as a side effect of "package require". If a
> script wants to use a newer API it has to call

>         package require Tcl $some_newer_version

The plan is not to remove the old APIs, just to add new ones.  There
is no replacement for the 'array' command, and 'unset' will still be
there, just with a '-nocomplain' option (I would be surprised if that
affected somebody's code).  There will be a new 'listx' command that
works like 'string', but all the old l* commands will still exist,
just as deprecated commands.

In this way, no code porting should ever be *required* in the 8.x
line, but there can continue to be improved features and commands
for those who want to write with them.

Tcl9 would be a different story, but one that's not yet written.

Quote:
> Retaining the old APIs should be a compile time option so one can get
> rid of the old stuff if he knows that he never has to run old scripts.

There is actually already a TCL_NO_DEPRECATED flag that you could
compile with.  I can't quite remember what it would remove, but I
think 'case' is probably taken out, along with several C API calls.
The default builds do not build with this flag though.

--
   Jeffrey Hobbs                          The Tcl Guy
   jeffrey.hobbs at scriptics.com         Scriptics Corp.



Fri, 08 Nov 2002 03:00:00 GMT  
 A suggestion for handling modifications in the core that change the script API

Quote:

> The plan is not to remove the old APIs, just to add new ones.  There
> is no replacement for the 'array' command, and 'unset' will still be
> there, just with a '-nocomplain' option (I would be surprised if that
> affected somebody's code).  There will be a new 'listx' command that
> works like 'string', but all the old l* commands will still exist,
> just as deprecated commands.

Maybe my wording was a bit misleading because I don't write in english
very often. So please give me the chance for a second try ;)

I didn't want to complain about removing old APIs, I wanted to
encourage removing old APIs on demand by doing "package require Tcl
8.4". The reason for this is that I think new APIs can be cleaner and
clearer if you don't require old and new APIs for the same thing to be
available at the same time. If someone then does "package require Tcl
8.4" he knows that he gets the APIs of 8.4 without any deprecated
commands.

Take "listx" as an example. I don't think this command name is very
intuitive. Why not have a "list" command in 8.4 that behaves the old
way by default or after a "package require Tcl
$any_version_before_8_4" and that behaves like the proposed "listx"
when "package require 8.4" is called. I am not against having "l*"
commands and "listx" at the same time as default after starting an
interpreter or requiring an older version, but I'd like to have
"listx" renamed to "list" and the "l*" commands removed after calling
"package require 8.4".

In the same way I'd prefer to have a "unset" that doesn't complain by
default and has a -complain option after "package require 8.4".

Quote:
> In this way, no code porting should ever be *required* in the 8.x
> line, but there can continue to be improved features and commands
> for those who want to write with them.

I think code porting would not be required, but encouraged by my
suggestion. If I just want to extend old scripts without completely
revising them, I can use "unset -nocomplain", "listx" and the old "l*"
commands. For new scripts however, I don't want to use workarround
command names or longish options.

If someone uses APIs that appeared in 8.4, his scripts won't run on
older interpreters anyway. So why not cleaning up the APIs and
dropping old commands when he clearly states that he wants to use 8.4?

Quote:
> Tcl9 would be a different story, but one that's not yet written.

Yes, and I think what I suggested would even simplify the transition
to 9.0 where "listx" possibly will be renamed to "list" anyway.

In the hope that I expressed myself better this time :)

cu
        Reinhard
--
If you put garbage in a computer  nothing comes out but  garbage.
But this garbage, having passed through a very expensive machine,
is somehow enobled and none dare criticize it.



Sat, 09 Nov 2002 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. need efficiency suggestions for graph modifications

2. Suggestion for Tcl modification

3. VMS Tk canvas bug (was: Re: SUGGESTION for modification to BUTTON widget)

4. SUGGESTION for modification to BUTTON widget

5. Batch Modifications / CSH Scripts

6. Q: Books on Forth Core Structure, Suggestions?

7. Looking to implement CORE Tcl only, need suggestions.

8. Tcl core dumps if Tcl API called before creating interpreter

9. 3D API suggestions

10. API suggestions invited

11. TIP #89: Try/Catch Exception Handling in the Core

12. TCL core: Better handling of arrays?

 

 
Powered by phpBB® Forum Software