[SC] Variable name contain <var>

[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:

Code: Select all

  ...
  unset *$s;
  $c--;
 }

EDITED. seriousized.

[admin]

I meant this example:

Code: Select all

$var = '$a';        *$var = "TEST"; echo $a;  //TEST

[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.

[admin]

Coming...

[bdeshi]

A Grrreat many thanks!

[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

Code: Select all

$var = '$a';

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

[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, ...

[admin]

Yeah, but too strange IMO. I will rather add real arrays.

[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

[binocular222]

I think PeterH's solution is a lot easier to read

[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.

[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...)

[TheQwerty]

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?

[PeterH]

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.

[admin]

I'd say $a$b$c without quotes is bad style, but I won't break it. It's been there too long.