php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #7553 RFC: Uplevel Block structure
Submitted: 2000-10-31 13:14 UTC Modified: 2010-12-01 15:50 UTC
Votes:6
Avg. Score:4.7 ± 0.7
Reproduced:5 of 5 (100.0%)
Same Version:3 (60.0%)
Same OS:4 (80.0%)
From: clcollie at mindspring dot com Assigned:
Status: Wont fix Package: Scripting Engine problem
PHP Version: 4.0.3pl1 OS: All
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2000-10-31 13:14 UTC] clcollie at mindspring dot com
Request For Comments: The Uplevel block structure
--------------------------------------------------
Very frequently it is useful to have a function perform actions which would benefit from a better knowledge of its calling environment. This would allow for more a more generic way of handling certain classes of problems. Hopefully the following example will demonstrate :

Very often, i would like to do something like the following :

function export_script_vars( $var_names ) {
   $result = "";
   foreach ($var_names as $var_name) {
      $result .= '<input type=hidden name="$var_name" value = "${$var_name}"/><br>'
   }
   return $result;
}

The intent of the script is to generally handle the export of a script's variables to hidden fields. The only problem, of course, is that the function has access only to its own symbol table, so to do something similar, we must resort to cut & past. This makes it impossible to have a generic function to perform this task. i can easily imagine other situations in which this occurs.

Proposal :
-----------
In TCL, there is the Uplevel syntax which allows a function to temporarily change its symbol scope to that of its parents within a program block.  This instructs the interpreter to search one level up for symbols unresolved in the current scope. The local symbol table would still be seached first (though im not sure if TCL handles it that way).

The syntax is similar to :

  uplevel {
    < Statements >
  }

or 

  uplevel (level) {
    < Statements >
  }

where level is the number of stack levels to "pop". Personally, the second option is not too important to me - the first would be fine.


With the proposed Uplevel syntax, the previous code would look like this ...

function export_script_vars( $var_names ) {
   $result = "";
   uplevel {
     foreach ($var_names as $var_name) {
        $result .= '<input type=hidden name="$var_name" value = "${$var_name}"/><br>'
     }
     return $result;
    }
}

With this addition, this opens great possibilities, though i can imagine the need to also be cautious.

Thanks for making PHP the great tool it is!

cc 
------------------------------------------------
"Fried Ice-Cream is a Reality!" - George Clinton

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2010-12-01 15:50 UTC] jani@php.net
-Status: Open +Status: Wont fix -Package: Feature/Change Request +Package: Scripting Engine problem
 [2010-12-01 15:50 UTC] jani@php.net
Cryptic, not PHP way, etc. Outdated as well.
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Sun Nov 19 01:31:42 2017 UTC