Re^5: Making a variable in a sub retain its value between calls

I'm talking about program run-time, not any file's run-time. If you have a module Foo that uses INIT you'll get a "Too late to run INIT block" warning if you require Foo during program run-time. E.g. you have

# Foo.pm
INIT { print 'Foo' }

# foo.pl
require Foo;
[download]

That won't execute like one would hope. By using INIT to initialize variables to constants you impose a completely unnecessary constraint on your module. No module that uses your Foo can be loaded at program run-time, meaning you can't ever use Foo, directly or indirectly, in any module that is dynamically loaded (like plugin modules). That's quite a serious limitation.

There's absolutely no reason, in general, for the initialization of the typical static variable to not happen at compile-time.

ihb

See perltoc if you don't know which perldoc to read!

Comment on Re^5: Making a variable in a sub retain its value between calls Select or Download Code

Replies are listed 'Best First'.
Re^6: Making a variable in a sub retain its value between calls by tlm (Prior) on Apr 19, 2005 at 00:36 UTC
We disagree on what we consider general programming practice vs. programming for special cases, but it seems to me that this is a tomayto-tomahto difference of opinion. Update: Perhaps I should clarify that, most of my programming is scripting, not module-writing, and of the module writing I do, 90% of it is OO classes. In the case of scripts, `INIT` is perfectly fine; it gives me a hook that I know will happen after all the `BEGIN`s I have scattered throughout my code. In my OO code I rarely if ever need static variables. the lowliest monk	[reply]
Re^7: Making a variable in a sub retain its value between calls by ihb (Deacon) on Apr 19, 2005 at 00:44 UTC
I assure you, it certainly isn't a tomayto-tomahto difference of opinion. This isn't about opinions. This is about not putting extremely excessive limitations on your code without reason. I get the feeling that you don't realize how far the consequences propagate -- the consequences go far beyond your reach as a module author. (Yes, the world will probably end, too. `;-)`) Any user that uses your module will be effected by this completely useless limitation. See CHECK and INIT under mod_perl and call a modules INIT-section for examples of when `INIT` can cause trouble. (The second problem is completely unnecessary and wouldn't have been a problem if the author would've understood the purpose of `INIT`, as I point out in my reply.) Reply to the update: Right, if you use it only for scripts it's OK, but if I'll have an opinion then it's that it's far better to use a solution that, in general, always works over a solution that, in general, sometimes works. I'm curious. When do you need to use `INIT`s to delay execution after all `BEGIN` blocks in scripts? `ihb` See perltoc if you don't know which perldoc to read!	[reply] [d/l] [select]
Re^8: Making a variable in a sub retain its value between calls by tlm (Prior) on Apr 19, 2005 at 01:22 UTC
I'm curious. When do you need to use INITs to delay execution after all BEGIN blocks in scripts? The point is that I don't have to even think about it. This is all very simple: I have a script, I have various bits of initialization code that need to be executed before run time scattered throughout; so I put them `INIT` blocks, without having to give a second's thought to what possible conflict any one of these INIT blocks may have with some BEGIN block later in the code. The point of using `INIT` blocks to solve the static variable initialization problem is to give the programmer the flexibility to arrange code as desired; otherwise it would have been sufficient to stick all subs with static variables at the top of the file. If one puts this initialization code in `BEGIN` blocks now one goes back to having to worry about the position of these initalization `BEGIN` blocks relative to other `BEGIN` blocks (including implicit ones in `use` statements) in the file, which makes no sense to me. the lowliest monk	[reply]
Re^9: Making a variable in a sub retain its value between calls by ikegami (Patriarch) on Apr 19, 2005 at 04:49 UTC
Re^10: Making a variable in a sub retain its value between calls by tlm (Prior) on Apr 19, 2005 at 05:46 UTC
Some notes below your chosen depth have not been shown here


Syntactic Confectionery Delight
	PerlMonks