Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Pls help old perl-monger with new version syntax?

Reply
Thread Tools

Pls help old perl-monger with new version syntax?

 
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-25-2012
http://www.velocityreviews.com/forums/(E-Mail Removed) writes:

[...]

> The snippet of code I included in my post was an attempt to come up
> with a process that would initialize these fields if they were not
> aleady defined. That's why I used the unless defined clause.
>
> My understanding of this function was that it was the perl equivalent
> of the php isset function. However, even when I remove the unless
> portion of the statements I still receive the same use of
> uninitialized variable blah blah.


Except that the error produced by your example code was something
different, namely,

Global symbol "$fn" requires explicit package name at a.pl line 5

and so on, for all variables used in it. And this error (not warning)
was caused by the fact that the unless defined(...) sub-statements
were outside of the scope of the my declarations and thus, accessed
undeclared package globals with full qualification.

The 'uninitialized value' (not variable) warning is very likely
produced when an automatic conversion of a so-called 'undefined value'
to either 0 or '' is done at runtime, except in some pretty random
looking subset of situations where this happens to be done. The best
way to deal with that, especially in known-to-be-working code, is

no warnings 'uinitialized';

which disables this warning. Alternatively, you can track down these
uses based on the warning output and include the necessary bogus
initializations to satisfy the coding pharisees ('Korinthenkacker'
would be more apropriate here but I don't know how to translate that
.
 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-25-2012
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> > Quoth Justin C <(E-Mail Removed)>:

>>
>> >> (though it's definitely preferred to declare them
>> >> only within the scope of where they're used)
>> >
>> > Yes. In general, don't create a variable until you have something useful
>> > to put in it. (This isn't always possible.)

>>
>> In general, don't declare variables in a lexical scope unless it
>> happens to be the outmost lexical scope of a subroutine. As soon as
>> this starts to become unwieldly, structure the code into a set of
>> subroutines and a controlling superroutine.

>
> Are you just contradicting me to be contrary, or do you have a point?


The point is that some odd 2x years of experience with it have taught
me that 'functional decomposition' is a good idea. This is also nicely
exposed by the fact that you didn't even try to argue against that but
went straight to the messenger (with a completely nonsensical
supposition -- maybe your wife/ girl friend/ current or perpetual sex
partner of choice argues with you for the sake of outacting
interelational stress, I certainly won't. I don't know you).

 
Reply With Quote
 
 
 
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-25-2012
Ben Morrow <(E-Mail Removed)> writes:
> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Ben Morrow <(E-Mail Removed)> writes:
>> > Quoth Rainer Weikusat <(E-Mail Removed)>:
>> >> Ben Morrow <(E-Mail Removed)> writes:
>> >> > Quoth Justin C <(E-Mail Removed)>:
>> >>
>> >> >> (though it's definitely preferred to declare them
>> >> >> only within the scope of where they're used)
>> >> >
>> >> > Yes. In general, don't create a variable until you have something useful
>> >> > to put in it. (This isn't always possible.)
>> >>
>> >> In general, don't declare variables in a lexical scope unless it
>> >> happens to be the outmost lexical scope of a subroutine. As soon as
>> >> this starts to become unwieldly, structure the code into a set of
>> >> subroutines and a controlling superroutine.
>> >
>> > Are you just contradicting me to be contrary, or do you have a point?

>>
>> The point is that some odd 2x years of experience with it have taught
>> me that 'functional decomposition' is a good idea.

>
> I agree entirely. This has nothing to do with whether you declare the
> variables in a particular function in a group at the top, or as you need
> them.


"I agree entirely. Provided you don't actually do that". As soon as
variables are being declared in inner scopes, a natural candidate for
factoring something out into a new subroutine has been found.
 
Reply With Quote
 
Justin C
Guest
Posts: n/a
 
      07-25-2012
On 2012-07-24, Ben Morrow <(E-Mail Removed)> wrote:
>
> Quoth Justin C <(E-Mail Removed)>:
>> On 2012-07-24, (E-Mail Removed) <(E-Mail Removed)> wrote:
>>
>> > my $fn = '' unless defined($fn);
>> > my $ln = '' unless defined($ln);
>> > my $opt = '' unless defined($opt);
>> > my $rr = 0 unless defined($rr);
>> > my $x1 = '' unless defined($x1);
>> > my $x2 = '' unless defined($x2);
>> > my $x3 = '' unless defined($x3);
>> > my $x4 = '' unless defined($x4);

>>
>> In addition to what others have said, I think this is
>> standard practice these days:
>>
>> my ($fh, $ln, $opt, $x1, $x2, $x3, $x4);
>> my $rr = 0;

>
> Neither '' nor 0 are the same as undef, so I'm not sure why you've
> singled out $rr here...


Of course, thank you for pointing this out. It's just that that is
what I usually do, unless I need to define something explicitly.
I've never had reason to define an empty string, 'undef' has always
been adequate for my needs.


>> (though it's definitely preferred to declare them
>> only within the scope of where they're used)

>
> Yes. In general, don't create a variable until you have something useful
> to put in it. (This isn't always possible.)


Now you tell me. I've been bending over backwards trying bend some
code to fit 'the rules'


Justin.

--
Justin C, by the sea.
 
Reply With Quote
 
Wolf Behrenhoff
Guest
Posts: n/a
 
      07-25-2012
Am 25.07.2012 15:25, schrieb Rainer Weikusat:
> Ben Morrow <(E-Mail Removed)> writes:
>> Quoth Rainer Weikusat <(E-Mail Removed)>:
>>> Ben Morrow <(E-Mail Removed)> writes:
>>>> Quoth Rainer Weikusat <(E-Mail Removed)>:
>>>>> Ben Morrow <(E-Mail Removed)> writes:
>>>>>> Quoth Justin C <(E-Mail Removed)>:
>>>>>
>>>>>>> (though it's definitely preferred to declare them
>>>>>>> only within the scope of where they're used)
>>>>>>
>>>>>> Yes. In general, don't create a variable until you have something useful
>>>>>> to put in it. (This isn't always possible.)
>>>>>
>>>>> In general, don't declare variables in a lexical scope unless it
>>>>> happens to be the outmost lexical scope of a subroutine. As soon as
>>>>> this starts to become unwieldly, structure the code into a set of
>>>>> subroutines and a controlling superroutine.
>>>>
>>>> Are you just contradicting me to be contrary, or do you have a point?
>>>
>>> The point is that some odd 2x years of experience with it have taught
>>> me that 'functional decomposition' is a good idea.

>>
>> I agree entirely. This has nothing to do with whether you declare the
>> variables in a particular function in a group at the top, or as you need
>> them.

>
> "I agree entirely. Provided you don't actually do that". As soon as
> variables are being declared in inner scopes, a natural candidate for
> factoring something out into a new subroutine has been found.
>


Just to make sure I understand you correctly: given the two following subs:

sub foo {
...
for my $i (1..100) { ... }
...
}

sub bar {
my $i;
...
for $i (1..100) { ... }
...
}

are you suggesting to prefer bar over foo because in foo the scope for
$i is limited to the loop? Isn't it much better to limit the variable to
the variable to the inner scope of the loop? If the loop does something
"complicated", it is a candidate

I prefer to declare a variable where I need it, this often is an inner
scope. However I agree with Ben and you that 'functional decomposition'
is a good idea and loooong subs should probably be split into smaller ones.

- Wolf


 
Reply With Quote
 
Wolf Behrenhoff
Guest
Posts: n/a
 
      07-25-2012
I wrote:
> If the loop does something
> "complicated", it is a candidate


.... for moving it into a new sub, of course. But if it just does some
"simple" operation, I wouldn't move it away.

(sorry, I had accidentally deleted this from the prev posting)

 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-25-2012
Wolf Behrenhoff <(E-Mail Removed)> writes:
> Am 25.07.2012 15:25, schrieb Rainer Weikusat:
>> Ben Morrow <(E-Mail Removed)> writes:
>>> Quoth Rainer Weikusat <(E-Mail Removed)>:
>>>> Ben Morrow <(E-Mail Removed)> writes:
>>>>> Quoth Rainer Weikusat <(E-Mail Removed)>:
>>>>>> Ben Morrow <(E-Mail Removed)> writes:
>>>>>>> Quoth Justin C <(E-Mail Removed)>:
>>>>>>
>>>>>>>> (though it's definitely preferred to declare them
>>>>>>>> only within the scope of where they're used)
>>>>>>>
>>>>>>> Yes. In general, don't create a variable until you have something useful
>>>>>>> to put in it. (This isn't always possible.)
>>>>>>
>>>>>> In general, don't declare variables in a lexical scope unless it
>>>>>> happens to be the outmost lexical scope of a subroutine. As soon as
>>>>>> this starts to become unwieldly, structure the code into a set of
>>>>>> subroutines and a controlling superroutine.
>>>>>
>>>>> Are you just contradicting me to be contrary, or do you have a point?
>>>>
>>>> The point is that some odd 2x years of experience with it have taught
>>>> me that 'functional decomposition' is a good idea.
>>>
>>> I agree entirely. This has nothing to do with whether you declare the
>>> variables in a particular function in a group at the top, or as you need
>>> them.

>>
>> "I agree entirely. Provided you don't actually do that". As soon as
>> variables are being declared in inner scopes, a natural candidate for
>> factoring something out into a new subroutine has been found.
>>

>
> Just to make sure I understand you correctly: given the two following subs:
>
> sub foo {
> ...
> for my $i (1..100) { ... }
> ...
> }
>
> sub bar {
> my $i;
> ...
> for $i (1..100) { ... }
> ...
> }
>
> are you suggesting to prefer bar over foo because in foo the scope for
> $i is limited to the loop?


There's no variable being declared in an inner scope in either example
so why do you ask? (NB: That's a stupid retort based on tangential
technicalities of the example).

> Isn't it much better to limit the variable to the variable to the
> inner scope of the loop?


Why?
 
Reply With Quote
 
Rainer Weikusat
Guest
Posts: n/a
 
      07-25-2012
Ben Morrow <(E-Mail Removed)> writes:

> Quoth Rainer Weikusat <(E-Mail Removed)>:
>> Wolf Behrenhoff <(E-Mail Removed)> writes:
>> >
>> > Just to make sure I understand you correctly: given the two following subs:
>> >
>> > sub foo {
>> > ...
>> > for my $i (1..100) { ... }
>> > ...
>> > }
>> >
>> > sub bar {
>> > my $i;
>> > ...
>> > for $i (1..100) { ... }
>> > ...
>> > }
>> >
>> > are you suggesting to prefer bar over foo because in foo the scope for
>> > $i is limited to the loop?

>>
>> There's no variable being declared in an inner scope in either example
>> so why do you ask?

>
> Yes there is.


Don't try to tell me what I "really meant to say". That's something I
know and you don't.

 
Reply With Quote
 
Jürgen Exner
Guest
Posts: n/a
 
      07-25-2012
Henry Law <(E-Mail Removed)> wrote:
>On 25/07/12 18:37, Ben Morrow wrote:
>>
>> Quoth Rainer Weikusat <(E-Mail Removed)>:

>
>I long since plonked Herr Weikusat. It's almost fun reconstructing what
>he must have said out of irritated posts from people who haven't done
>the same.


))


jue

 
Reply With Quote
 
Tim McDaniel
Guest
Posts: n/a
 
      07-25-2012
In article <(E-Mail Removed)>,
Ben Morrow <(E-Mail Removed)> wrote:
>
>Quoth Henry Law <(E-Mail Removed)>:
>> On 25/07/12 18:37, Ben Morrow wrote:
>> >
>> > Quoth Rainer Weikusat <(E-Mail Removed)>:

>>
>> I long since plonked Herr Weikusat. It's almost fun reconstructing
>> what he must have said out of irritated posts from people who
>> haven't done the same.

>
>I apologise if my replies are becoming irritating.


No, no! Your posts are almost always valuable. Irritating messages
annoy the recipient; irritated messages are when that annoyed reader
writes about it. Irritated articles are sometimes among the funniest
or most informative. Exemplia gratia, http://notalwaysright.com/ , or
Mark Twain on Cecil Rhodes.

--
Tim McDaniel, (E-Mail Removed)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
URGENT - Pls help...pls recommend - laptop purchase irfansmith@gmail.com Computer Information 2 08-15-2008 11:34 PM
Re: Where to get stand alone Dot Net Framework version 1.1, version2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? MowGreen [MVP] ASP .Net 5 02-09-2008 01:55 AM
Re: Where to get stand alone Dot Net Framework version 1.1, version 2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? PA Bear [MS MVP] ASP .Net 0 02-05-2008 03:28 AM
Re: Where to get stand alone Dot Net Framework version 1.1, version 2.0, version 3.0, version 3.5, version 2.0 SP1, version 3.0 SP1 ? V Green ASP .Net 0 02-05-2008 02:45 AM
pls, help.. i need a number..pls olabanji timothy MCSE 7 09-10-2003 04:02 PM



Advertisments