Ticket UUID: | 959831 | |||
Title: | doc: global and qualified varNames? | |||
Type: | Bug | Version: | None | |
Submitter: | msofer | Created on: | 2004-05-25 01:44:07 | |
Subsystem: | 07. Variables | Assigned To: | msofer | |
Priority: | 3 Low | Severity: | ||
Status: | Closed | Last Modified: | 2005-08-28 08:38:58 | |
Resolution: | Fixed | Closed By: | msofer | |
Closed on: | 2005-08-28 01:38:58 | |||
Description: |
The manual pages for global and upvar commands do not explain the behaviour when the variable names contain namespace qualifiers. This is not so bad for upvar, as the behaviour is quite intuitive. Not the same for global ... One possibility is to explain global's behaviour, and show that it could be defined as proc global args { if {[info level] < 2} { return } set cmdName [namespace tail [lindex [info level -1] 0]] if {[info procs $cmdName] eq {}} { return } set cmd [list upvar 0] foreach var $args { lappend cmd ::$var [namespace tail $var] } uplevel 1 $cmd return } | |||
User Comments: |
msofer added on 2005-08-28 08:38:57:
Logged In: YES user_id=148712 Moved the [upvar] issue to Bug #1274918, closed the ticket and changed the summary accordingly msofer added on 2004-05-26 03:16:37: Logged In: YES user_id=148712 global.n fixed; upvar.n not yet ... jenglish added on 2004-05-26 01:29:41: Logged In: YES user_id=68433 New text looks good, though I'd suggest leaving out the part about "global can be defined in terms of other builtin commands as: [...]". The Tcl equivalent doesn't make things any clearer, since to understand it you first have to understand all the details of [info level], [namespace tail], [upvar], and [uplevel]. (Plus, I'm not sure it's even correct). msofer added on 2004-05-25 23:58:44: File Added - 88378: global.n msofer added on 2004-05-25 23:58:43: Logged In: YES user_id=148712 Attached proposal for global.n; request comments |
Attachments:
- global.n [download] added by msofer on 2004-05-25 23:58:44. [details]