This isn't possible in normal Perl (with XS, Deparse, source filters, B::*, almost anything is possible). See, a variable
name is just another reference to a value. It's like
this:
+----------+
| |
| Variable |
| |
+----------+
|
|
V
+-------+ +-----------+
| | | |
| Value |<---------| Reference |
| | | |
+-------+ +-----------+
There's no way "back" from the value to the variable (name).
In fact, a value could have several names (think what
Exporter does, or the aliasing that happens in a for loop),
or no name at all.
Abigail | [reply]
[d/l] |
There really isn't an easy and pure-Perl way to figure out what names are attached to a particular scalar, array, or hash.
If you find yourself needing to find variable names, you may be better off storing your data in hashes where at least you can easily get a list of keys.
But basically if you find yourself needing to rediscover variable names, you probably have a design flaw. Maybe you could explain a little more about the situation so we could help with designing a solution.
| [reply] |
Well Dave, its like this ..
I am trying to write a module which can give the
functionality of a database created using arrays and hashes ..
i.e. create a virtual in memory database using arrays and hashes which could act as tables.
And then allow running simple SQL statements to process data in these arrays/hashes just like database tables.
eg. 1
If the user choses to create the database using one "two dimensional array" named sales,
I want him to be able to process the data in array sales using a simple query like ..
select 0,sum(1) from sales group by 0 order by 0
where 0 n 1 are the columns of array sales.
O/P would be an array.
This avoids the need for writing nested for loops in the calling program ..
eg. 2
user creates a database using a one "two dimensional" salary array and one "hash" parameters..
Then he could use a query like below to select all the rows
from array salary which have the salary value above a specified min salary.
select salary.* from salary,parameters where salary.1 > parameters.minsal order by salary.0
Ofcourse these are hypothetical examples and one would be
better off getting processed o/p from the database itself.
But this module which I am writing is for cases where my datasource is not database,
and I need to have the ease of processing my datastructures like database tables.
Let me know if more details are required.
| [reply] |
If you just want the benefits of an "in memory" database, then why not use DBD::SQLite instead.
And can you please fix the formatting on that post please. The "pre" tags make it look really nasty.
--
< http://www.dave.org.uk>
"The first rule of Perl club is you do not talk about
Perl club."
-- Chip Salzenberg
| [reply] |
There are some expensive techniques involving trawling the symbol table, then every pad in every format and code reference which might be able to locate all the names by which a certain variable is referenced. If that failed then it might also be possible to write some C code to trawl through perl's arenas. The thing is, this is going to take a bunch of runtime because each lookup has to check a few thousand locations (if you're lucky). You'll be better off thinking of a different solution. Perhaps like SQLite or DBD::CSV.
| [reply] |