Re^5: Use of uninitialized variables?

I've already stated I think you're obviously doing something wrong if you're initializing something twice.

We're in violent agreement that you shouldn't initialize something twice; this is simply an illustrative example of what happens when you do, as is being recommended to me. It *looks* like undef or () is being assigned right away, but it's not, depending on how the module is used. The assignment at a later point is supposed to be the initial value, NOT the value on the same line. By assigning early you can cause problems, which is the point of the example above. Initializing these values that you expect to initialize later is a completely superfluous and potentially (as shown in the above example) disastrous process.

Comment on Re^5: Use of uninitialized variables?

Replies are listed 'Best First'.
Re^6: Use of uninitialized variables? by ikegami (Patriarch) on Jun 12, 2008 at 19:57 UTC
as is being recommended to me What the OP quoted wasn't nearly that specific. Keep in mind the goal of an idiom or practice when applying it. In this case, it's for "the readers of the code can immediately see that the lack of definition is intentional". That means that `my $var; BEGIN { $var = ...; }` [download] satisfies the requirements. You can even put those two statements on the same line. I provided an example above of what would satisfy the practice if you had some complex initialization code in a previous post in this thread. You always have to be very careful when using BEGIN blocks to make sure all the code that should be in a BEGIN block is in a BEGIN block. You've shown an example of this already when the inline module that did everything right was messed up by a BEGIN block in its user. Basically, what I'm saying is you can't change `my $var = "some value"; ... code that uses $var ...` [download] to `my $var = "some value"; BEGIN { ... code that uses $var ... }` [download] You need to change it to `my $var; BEGIN { $var = "some value"; ... code that uses $var ... }` [download] If you're particularly "picky", you could use `my $var; BEGIN { $var = "some value"; } BEGIN { ... code that uses for $var ... }` [download] It has nothing to do with whether "some value" is there because PBP recommended it, or because it needs to be there for the code to function. I don't agree with the practice the OP quoted, but badly applying BEGIN blocks is not an argument against the practice.	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^6: Use of uninitialized variables?
by ikegami (Patriarch) on Jun 12, 2008 at 19:57 UTC

as is being recommended to me

What the OP quoted wasn't nearly that specific. Keep in mind the goal of an idiom or practice when applying it. In this case, it's for "the readers of the code can immediately see that the lack of definition is intentional". That means that

my $var;
BEGIN {
   $var = ...;
}
[download]

satisfies the requirements. You can even put those two statements on the same line. I provided an example above of what would satisfy the practice if you had some complex initialization code in a previous post in this thread.

You always have to be very careful when using BEGIN blocks to make sure all the code that should be in a BEGIN block is in a BEGIN block. You've shown an example of this already when the inline module that did everything right was messed up by a BEGIN block in its user.

Basically, what I'm saying is you can't change

my $var = "some value";
...
code that uses $var
...
[download]

my $var = "some value";
BEGIN {
   ...
   code that uses $var
   ...
}
[download]

my $var;
BEGIN {
   $var = "some value";
   ...
   code that uses $var
   ...
}
[download]

If you're particularly "picky", you could use

my $var; BEGIN { $var = "some value"; }

BEGIN {
   ...
   code that uses for $var
   ...
}
[download]

It has nothing to do with whether "some value" is there because PBP recommended it, or because it needs to be there for the code to function. I don't agree with the practice the OP quoted, but badly applying BEGIN blocks is not an argument against the practice.

[reply]
[d/l]
[select]