Hello rkabhi,

As haukex says, the Switch module is deprecated and therefore best avoided. But the problem here is not with the module, but rather with the way it is being used.

First, by giving the switch statement an empty argument, you are matching against the empty string:

use strict;
use warnings;
use Switch;

for ('abc', 'def', 'ghi')
{
    switch ()
    {
        case /bc/ { print "$_: matches 'bc'\n"; }
        case /de/ { print "$_: matches 'de'\n"; }
        case ''   { print "EMPTY STRING\n"; }
        else      { print "$_: no match found\n"; }
    }
}
[download]

Output:

 1:51 >perl 1675_SoPW.pl
EMPTY STRING
EMPTY STRING
EMPTY STRING

 1:51 >
[download]

You need to specify the string to be matched against: in this case, switch ($_) {.

Second, the next statements in your case clauses do not force another iteration of the enclosing while loop, as you expect. That’s because the Switch module uses next to implement fall-through, as explained in the “Allowing fall-through” section of the Switch documentation. You could avoid this by specifying an explicit target for the next statements; for example (untested):

MAIN_LOOP: while (<READ_NETLIST>) {
    chomp;
    s/^\s+//;       # Remove leading blanks (if any) in the line
    # ignore line if it contains comments or initializing words for sp
+ectre
    switch ($_) {
        case /^[*\/]/i           { next MAIN_LOOP; }
        case /simulator\s+lang/i { next MAIN_LOOP; }
        case /^include/i         { next MAIN_LOOP; }
    }
    ...
}
[download]

Hope that helps,

Hi Athanasius,

Thanks for your response.

Regarding the empty string. I tried running your example code using perl 5.10.1 and got following output:

OUTPUT WITH EXAMPLE CODE:


abc: matches 'bc'
def: matches 'de'
ghi: no match found
[download]


So, somehow we get different outputs. Not sure why. Since in my case it tries to match with $_ when nothing is specified in switch(), I could not identify any issue with such use of switch and therefore I continued using it.

Thanks for mentioning things to take care as best practice about using empty arguments and next statements. I will try your suggestions and get back if the main issue persists. For now I am not going to use switch as it is not necessary for my code.

Best Regards,
Abhishek

I tried running your example code using perl 5.10.1 and got following output...

Interesting. Experimenting with the Strawberry Perl versions I have on my system, it appears the change occurred between Perl 5.12.3 and 5.14.4. Running with -MO=Deparse reveals only one difference:

&Switch::switch();    # v5.12.3
vs.
&Switch::switch(());  # v5.14.4
[download]

And calling switch explicitly with an empty list — switch(()) — under 5.12.3 gives the same result as calling switch() under 5.14.4.

I’ve skimmed through the deltas, but so far haven’t found a plausible explanation. Possibly related to the change in handling the (;$) prototype,¹ since that is the prototype of sub switch in the Switch module, but I don’t see how that would account for the observed behaviour. :-/

¹See “Change in parsing of certain prototypes” in perl5140delta.

Cheers,

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

Welcome, rkabhi.

Is there any particular reason why you are not running the latest version of Perl?

Hi Abhishek,

Please use <code> tags to format your code and example input. See also How do I post a question effectively?

A first quick analysis is that your problem seems to stem from the use of the Switch module - its use is discouraged, please see the section "Limitations" in its documentation. If I replace the switch statement with next if /^[*\/]|simulator\s+lang|^include/i;, your code appears to run the same no matter the order of the subroutines.

There may be other possible places for improvement, I haven't read the code in detail yet, but that seems to be the main problem.

Hope this helps,
-- Hauke D

Hi Hauke,
Thanks a lot for quick response !!
Your response really helped.

I am actually writing few perl codes for the first time for a project and want to be cautious with use of such modules. Is there any way I can get to know those basic modules whose use is not suggested?

Thanks once again for your help!!

--
Abhishek

Hi Abhishek,

Modules whose use is discouraged is often noted in the module's documentation itself (for example, the top of the Switch page says "do not use if you can use given/when"). Otherwise, by looking at a distribution's CPAN page (this is the one for Switch), there are other clues as to when a module might not be good to use: if it has bad reviews, if it only had one release and/or hasn't had releases for many years, if its test statistics show a lot of failures, and/or if it has a lot of unresolved bugs. None of these things by themselves make a module bad, they are only clues, but if a module has a lot of these issues then you may want to stay away from it. The same clues can of course be used to tell if a module is "good": good reviews, several releases over several years, a low bug count, and good test results are all signs of a module being "good quality".

Off the top of my head, some modules that are often used even though their use is nowadays discouraged: XML::Simple (is only useful for a very narrow range of tasks, there are better modules like XML::Twig, XML::Rules, or XML::LibXML), Switch (a few alternatives), and CGI (there are more modern web frameworks, such as Catalyst, Dancer/Dancer2, and Mojolicious). <update> File::Slurp has a lot of issues, better to slurp manually or use one of the other modules. </update>

On the other hand, you can get a lot of good module suggestions from this site itself by reading threads with questions that relate to your tasks, or there is also Task::Kensho, a list of recommended modules for various tasks.

Hope this helps,
-- Hauke D