On 12/01/2022 07:08, Alex Peshkoff via Firebird-devel wrote: > On 1/11/22 22:15, Adriano dos Santos Fernandes wrote: >> Hi! >> >> Currently sub routines cannot access the outer (main routine/block) >> variables, parameters and cursors - #4769. >> >> There is some details to make that happen safely. >> >> Currently a variable cannot have its value changed while its being used. >> >> var = var + <expression> > > Not clear - you provide some proposition and right after it a sample > disproving it. >
I'm saying that *currently* (before a change) that not happens. After the change, expressions would be able to change variables (when function is called and changes main routine's variables). >> No expression can reset var. >> >> As soon we let sub routines change outer variables, that will be >> possible. >> >> Currently VariableNode just returns a descriptor pointing to the >> variable's impure_value present in the variable declaration. >> >> To make outer access safe, variables accessed in outer scope would be >> flagged and its VariableNode (even in the main routine/block) should >> copy the value to its own impure_value. It will be a bit slower, but I >> don't see a problem. >> And then I'm saying how to make that not be a problem. >> What worried me more is how to represent things in BLR. A simple >> approach would be to have blr_outer_variable. >> >> But it is not only variables. >> >> There is also parameters, fields, dbkeys, cursor statements. >> >> What seems for me the way to go is to implement single blr_outer_map >> that maps main routine's things to sub routines in they own number space. >> >> blr_outer_map, >> blr_outer_map_variable, >> 0,0, >> 3,0 >> >> It maps main's variable 0,0 to this sub routine's 3,0, so it can access >> with blr_variable, 3,0. >> >> blr_outer_map, >> blr_outer_map_cursor, >> 1,0, >> 2,0 >> >> Maps main's cursor 1,0 to this sub routine's 2,0, so it can access with >> blr_cursor_stmt, 2,0. >> >> Comments? > > Provided mapping always begins with blr_outer_map do we really need > blr_outer_map_variable, blr_outer_map_cursor, etc. BLR codes? Is not it > enough to take into an account blr_outer_map before and use existing > blr_variable, etc.? > I prefer to have specific sub commands there. It's more clear. Otherwise parse code would be need to be read to understand what can be mapped. Also, clever schemes may be used, as single blr_outer_map with all sub commands for the whole sub routine. Adriano Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
