in reply to scoped namespace?

Your question is a bit sketchy on the details of what you doing. In particular, what you mean by showing up where it's not supposed to, but I think that you might be able to use package scoping to achieve you aim. 

package foo_name_space;
eval "require './data_to_import.dat'";  
package main; ## or your module name
$self->{imported_data} = $foo_name_space::data unless $@; 
}

[download]

I think that would get you part way to your goal at least. Any vars created would be in the 'other' package space, and so isolated from your code.

This would probably work well if any vars created were overwritten with the new data each time the code was invoked, but if new variables are created each time, then the old ones would persist and you would have a memory leak which wouldn't bode well in a mod_perl environment.

Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


Replies are listed 'Best First'.
Re: Re: scoped namespace?
by Anonymous Monk on Jun 17, 2003 at 00:25 UTC

    The dumped data is filled into a file that has a package declaration at the top that is pretty uniform across all the dumps.

    There are hundreds of these dumps (serialized data) across a directory structure.

    Certain parts of this directory structure are made available to certain users of this web app (similar to Unix filesystem access rules).

    Thus, the data contained in these dumps are pertinant to the group the user is a member of. Since this data is stored in a uniform namespace (the package delcaration that is the same across all the dump files), the data shows up (due to mod_perls persistance) even though the object falls out of scope. So a few refreshes from one session might accidentally show the data from another session (this seems to be the case in a low percentage of views, say one in ten).

[reply]
      (this seems to be the case in a low percentage of views, say one in ten)

      Let me guess... you start 10 server processes... right?

      Try starting just a single server and see if that doesn't raise your 1 in 10 to a hundred percent. ;-)

      I think you should certainly be doing this another way (say, encapsulating the data in an object rather than using a package's whole namespace, for instance.) But, I understand you are already entrenched and trying to make a go of what you currently have... Still, I'd consider some sweeping changes for the next revision.

      -sauoq
"My two cents aren't worth a dime.";
[reply]

      In the light of the further info, my suggestion does help at all.

      Given the status quo, sauoq's suggestion of Symbol::delete_package (used as early as possible) seems about the best your going to get without pretty fundemental changes to your app architecture.

      I keep wondering if you couldn't rename the uniform package statements to use some sort of hierarchal naming convention and then use that to restrict what information the user sees according to their group rights, but that sort of change is probably so extensive, that you would be better off rewriting from scratch to use a better architecture.

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


[reply]

In Section Seekers of Perl Wisdom