>>>>> "APK" == Akhthar Parvez K <akht...@sysadminguide.com> writes:
APK> 1) Since a hash defined in the main part (outside the APK> subroutines) of a program can be accessed from anywhere (from all APK> subroutines), is it fine, in regards to security or even code APK> elegancy, if we define a hash in the main part? An advantage with APK> defining in the main part is there's no need to pass it as an APK> argument while calling a subroutine. But is that the right APK> method? there are two ways to declare (not define) a hash at a file scope (which is what you are calling main part). my declares it lexically to the file which is decent if needed. our declares it as a package global which means it can be accessed from any code using the fully qualified name or it can be exported too. both have their uses. but using globals in general is not a good idea if you can avoid it. the issues are well know and include action at a distance (some other code can modify your hash and you won't know why/where/what about it). passing data is safer because it isolates the data to the code that needs it. isolation is a major coding philosophy all coders need to learn. isolated code means you can test more easily (no side effects or outside code to worry about). you can replace isolated code easily as it isn't intertwined with other code and data. APK> 2) Is it advisable to use 'our', except with package, to define a APK> variable in the main part (as this can be done with 'my')? I APK> would also like to know the security concerns with our', that APK> what are the issues if we define a scalar variable with 'our' APK> instead of 'my'. security isn't the issue, access is. i pretty much covered that in the first answer. APK> 3) Also, am I correct in guessing that the memory that's used to APK> allocate a variable defined with 'my' will be freed up once the APK> current lexical scope is exited? true but with a file lexical (or global) that won't happen until the program exits. this is another reason to declare things in the tightest scope possible. also note that the memory is freed up for perl to reuse, not for the OS. it will mean perl won't need to grow its size if it can reuse lexical data that is reclaimed upon scope exit. uri -- Uri Guttman ------ u...@stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
