Page 2 of 3
Re: [SC] Variable name contain <var>
Posted: 16 May 2014 17:25
by bdeshi
My brain must've gone to sleep.
How do I make deferencing work with set and unset?
Tried this:
Code: Select all
$c=13;
while($c>0){
$s = '$d'.$c;
set *$s, $c;
$c--;
}
With same code tried this to unset:
EDITED. seriousized.
Re: [SC] Variable name contain <var>
Posted: 16 May 2014 18:25
by admin
I meant this example:
Code: Select all
$var = '$a'; *$var = "TEST"; echo $a; //TEST
Re: [SC] Variable name contain <var>
Posted: 16 May 2014 18:43
by bdeshi
Yes, I know, (set command isn't much used anyways) but please make it work with unset at least. It feels so old to use the former methods now...
In you own time of course.
Re: [SC] Variable name contain <var>
Posted: 16 May 2014 20:02
by admin
Coming...

Re: [SC] Variable name contain <var>
Posted: 16 May 2014 20:16
by bdeshi
A Grrreat many thanks!

Re: [SC] Variable name contain <var>
Posted: 17 May 2014 13:10
by Filehero
Hi,
Code: Select all
$var = '$a'; *$var = "TEST"; echo $a; //TEST
having noch C/C++/pointer experience but only OO background I'm still struggling with the example given above. Yesterday I did look up
dereferencing and thought I got it, but the again I ......
At least now I think the critical statement isn't the new operator (the consept is quite clear, don't touch/change the pointer but it's target/the "value"), instead the crucial part rather is
All the time I thougt this is creating a pointer having a char array value containing 2 chars (and a null char internally as well). But for the new logic to work this statement in fact has to create a new 'empty' variable.
I assume in Java it is equivalent to
Code: Select all
String a; // declaration, no initializisation
String var = "Test"; // declaration & initializisation
a = var;
Not an urgent one .. but puzzling.
Cheers,
Filehero
Re: [SC] Variable name contain <var>
Posted: 17 May 2014 15:27
by PeterH
Current solutions of dereferencing don't allow to *use* such a var, only allows to set...
What about a kind of 'hierarchical var name calculation'?
(Maybe only outside quotes:) $a$n might be calculated right-to-left, so that
Code: Select all
$n = 4;
$a$n = 'text'; // sets $a4 to 'text'
echo $a$n; // shows contents of $a4
(To *concatenate* contents of $a and $n, especially outside quotes, $a.$n should be used.)
Also:
Code: Select all
$name = 'abc';
$$name = 'text'; // sets $abc
echo $$name; // shows contents of $abc
Also $a$b$c should be possible...
Result: complete "variable variable-names", even simulation of arrays possible, ...
Re: [SC] Variable name contain <var>
Posted: 17 May 2014 15:31
by admin
Yeah, but too strange IMO. I will rather add real arrays.
Re: [SC] Variable name contain <var>
Posted: 17 May 2014 17:43
by admin
BTW, what you can do is this using eval():
Code: Select all
$name = '$abc';
*$name = 'text'; // sets $abc
echo eval($name); // shows contents of $abc
Re: [SC] Variable name contain <var>
Posted: 17 May 2014 17:56
by binocular222
I think PeterH's solution is a lot easier to read
Re: [SC] Variable name contain <var>
Posted: 17 May 2014 22:19
by TheQwerty
I think using eval is sufficient and makes the intent of the code clearer.
'$a$n' also runs the risk of possibly breaking older scripts.
Re: [SC] Variable name contain <var>
Posted: 18 May 2014 00:44
by PeterH
2 versions of sample code
- first as it works now
- second with $a$b$c syntax:
Code: Select all
$vn = 4;
$vt = "caption";
$name = '$var' . $vn . $vt;
*$name = 'Title or so';
// ... some code, $vn and $vc will be independent: must recalculate $name!
$name = '$var' . $vn . $vt;
echo "var '$vn' '$vt' = '" . eval($name) . "'";
<<<--- ............................ --->>>
$vn = 4;
$vt = "caption";
$var$vn$vt = 'Title or so';
// ... some code, $vn and $vc will be independent: does not matter!
echo "var '$vn' '$vt' = '" . $var$vn$vt . "'";
I think the second version looks simpler, and more direct.
It should not break old code if only allowed outside quotes?
Currently $a$b (or $var$vn$vt as above) outside of quotes is not allowed?
By the way: maybe
debug-info in step-dialog doesn't really show the result of
*$name = 'text'; 'parsed and resolved': as *$name is shown as the variable name, while it's resolved to $a4
(So you can't see
which variable is set...)
Re: [SC] Variable name contain <var>
Posted: 19 May 2014 00:26
by TheQwerty
PeterH wrote:2 versions of sample code
- first as it works now
- second with $a$b$c syntax:
Code: Select all
$vn = 4;
$vt = "caption";
$name = '$var' . $vn . $vt;
*$name = 'Title or so';
// ... some code, $vn and $vc will be independent: must recalculate $name!
$name = '$var' . $vn . $vt;
echo "var '$vn' '$vt' = '" . eval($name) . "'";
<<<--- ............................ --->>>
$vn = 4;
$vt = "caption";
$var$vn$vt = 'Title or so';
// ... some code, $vn and $vc will be independent: does not matter!
echo "var '$vn' '$vt' = '" . $var$vn$vt . "'";
I think the second version looks simpler, and more direct.
It should not break old code if only allowed outside quotes?
Currently $a$b (or $var$vn$vt as above) outside of quotes is not allowed?
Quoting has always been optional so the following is entirely acceptable:
Code: Select all
$a = 1;
$b = 2;
$c = 3;
echo $a$b$c; // Echo's '123'.
No idea how many old scripts rely on this method for operator-less concatenation, and sure it is only a true problem when the now dereferenced variable name is the same as existing variable names, but I don't like the idea of having to trace back variables to discover they are dereference earlier.
That ambiguity alone makes it impossible for me to ever see how the second example is better. Is it clearer? Only if you know enough about the code - but that burden of knowledge is costly.
Isn't this particular problem also solved by the Set SC's reprocess flag?
Re: [SC] Variable name contain <var>
Posted: 19 May 2014 11:03
by PeterH
TheQwerty wrote:Quoting has always been optional so the following is entirely acceptable:
Code: Select all
$a = 1;
$b = 2;
$c = 3;
echo $a$b$c; // Echo's '123'.
No idea how many old scripts rely on this method for operator-less concatenation, and sure it is only a true problem when the now dereferenced variable name is the same as existing variable names, but I don't like the idea of having to trace back variables to discover they are dereference earlier.
That ambiguity alone makes it impossible for me to ever see how the second example is better. Is it clearer? Only if you know enough about the code - but that burden of knowledge is costly.
Isn't this particular problem also solved by the Set SC's reprocess flag?
As far as I remember the $a$b$c outside quotes if wrong/illegal syntax since the time quoting was invented.
And I think it belongs to the kind of expression Don said about: it can stop to work at any time...
Maybe Don can say whether I'm right here.
Sad that especially with quoting people often use wrong syntax and say it must be right - as it works. But right is what's described in syntax definition - not what works by chance.
Re: [SC] Variable name contain <var>
Posted: 19 May 2014 11:08
by admin
I'd say $a$b$c without quotes is bad style, but I won't break it. It's been there too long.
