This is not necessarily the current version of this TIP.This is not necessarily the current version of this TIP.
| TIP: | 10000 |
| Title: | Dummy Proposal for Testing Editing Interfaces |
| Version: | $Revision: 1.54 $ |
| Authors: |
Don Porter <dgp at users dot sourceforge dot net> nobody at nowhere dot com Andreas Kupries <akupries at westend dot com> Donal K. Fellows <fellowsd at cs dot man dot ac dot uk> Andreas Kupries <a dot kupries at westend dot com> dgp at user dot sourceforge dot net Richard Suchenwirth <richard dot suchenwirth at kst dot siemens dot de> Kevin B KENNY <kennykb at acm dot org> |
| State: | Draft |
| Type: | Informative |
| Vote: | Pending |
| Created: | Sunday, 03 December 2000 |
This proposal has no content. It exists only to provide a document on which testing of and practice using of the TIP editing interfaces can take place.
This document serves a purpose similar to the Graffiti page (http://purl.org/thecliff/tcl/wiki/34.html) at the Tcl'ers Wiki (http://purl.org/thecliff/tcl/wiki/).
It will also be useful for testing the web editing interface proposed in TIP #13.
Some browsers are spinning their wheels after submission... Looks like this is fixed now.
Checking fix for missing Abstract after adding a new Author... Fixed.
See if additional HTTP headers help... Yes.
Attempt to add a new section via the web interface (in a frame).
Are anonymous changes possible?
Check that updates of TIP renderer didn't break editing...
<Andreas Kupries> Just my first try at the new web editing interface for TIPs.
Hm ... Maybe we could add a direct reference to TIP #3 to the edit page for easy/quick lookup of the formatting (rules|definition). It should open into its own window, immediately, when following the link.
I miss a button or some such which allows me to enter a new TIP. Currently it seems as if I can just edit an existing document.
More: After submitting the changes I had to explicitly reload the TIP frame to see my changes. This is most likely a browser problem, but I think we should add a note to the edit page about this, or people might assume that their changes were lost in some way, and perceive the service as unreliable.
That's it for now. ... I'll add the same comments to TIP #13, they belong there more than here. </Andreas Kupries>
<note by="Richard Suchenwirth" date="2001-01-30">Whitespace in XML element names won't work.. or is "Kupries" an attribute without value?</note>
Move along now; nothing to see here...
This document has been placed in the public domain.
$Log: 10000.tip,v $ Revision 1.54 2001/03/07 21:13:16 tclhttpd Revision through web from Kevin B KENNY <kennykb@acm.org> (19525) index) } set x [list 1 2 3] increment x 0
will, of course, work as expected.
There are several obvious extensions to the proposal that are not addressed, and these omissions are intentional.
One possibility is to provide a syntax (perhaps negative subscripts) to allow numbering from the end of the list as well as the beginning.
Another possibility is to provide a notation for multiple subscripts, to allow surgical changes to be made in lists of lists.
These changes are not addressed primarily because the author of this TIP foresees that they are likely to cause undesirable interactions with future attempts to implement other types of indexed data structure, such as the maps, vectors, and matrices of products like BLT and Feather. In a fully developed Tcl 9.0, it would be desirable for all of these objects to support similar interfaces; this TIP proposes a minimal first step.
The array command continues to operate only on associative arrays.
Lists are a simple enough structure that the full power of the array command is not required to deal with them, and having it work on lists as well as arrays seems like needless effort. Moreover, existing code may well depend on a combination of [array exists] and [info exists] to distinguish associative arrays from scalar variables (including lists).
We might wish to extend upvar syntax to allow a list element to be designated.
Extending the syntax in this fashion would make upvar more consistent in its behavior, but appears to be expensive, in terms of both performance (tracking down the linked references if a list is rebuilt) and the effort required for implementation (the author of this TIP is unlikely to have the time required to implement the necessary changes to struct Var and the associated code). In fact, the author of this TIP would much rather deprecate the use of upvar to refer to array elements. A disproportionate amount of code goes into supporting this seldom-used feature.
No reference implementation has yet been developed; the author of this TIP wishes to solicit the opinions of the Tcl community before spending a lot of time implementing a possibly bad idea.
This document has been placed in the public domain.
This is not necessarily the current version of this TIP.