A clearer control default values like my $var ||= $default without the 0 value gotcha.
The newest development versions of perl have a "defined-or" operator //, so the //= operator does that. There's even a patch you can apply to perl-5.8 to have that operator. The only sad part is that we'll have to wait a while until it's widely available for general use. | [reply]
[d/l]
[select] |
The advantage to case statements is that each element is not mutually exclusive, as you have with a single if/elsif/else structure
So, in pseudocode, you might do something like:
switch (value) {
case 'needs_slight_cleaning':
&clean_up_values;
case 'good value':
&do_whatever_you_need_to;
break;
case 'totally unrelated';
&do_something_else;
break;
default:
&do_some_default_thing;
}
Note how there is no 'break' between the first two cases, so something that matches the first case will run '&clean_up_values' and '&do_whatever_you_need_to';
It's not an absolutely necessary control structure, but there are some times when it sure does come in handy. (most times when you have a giant if/elseif/else tree, where you're repeating large blocks of it).
Update: I forgot to answer the questions as they were asked:
- What type of new control structures you would like to have in Perl?
- I'm fine with the current structures
- What would be your consideration for the design of control structures ?
- Anything that helps me get my work done
- Would that make your task easier?
- switch/case statements, for the reason stated above.
Can you mimic them with current version (5.6+)?- Yes. With goto.
| [reply]
[d/l] |
| [reply]
[d/l] |
Um...the goto bit was a joke. (although, it does come in handy for these sort of logic issues)
But your example structure still doesn't behave like switch/case in C (okay, I did more LPC than I've ever done C, and that was all a long time ago). The important thing is that matching 'needs_slight_cleaning' does not mean that it matches 'good_value', or that it will match after &clean_up_values is called.
Because I've been doing without switch for so long, it's difficult to think of examples when these structures are really useful. Once you see the logic, it makes perfect sense, though.
Okay, here's a logic situation -- you have a program that's monitoring servers. You based on a given alert, you need to decide how to escallate.
switch ($machine_name) {
# master LDAP server:
case 'einstein':
&alert_management();
# LDAP replicas
case 'joule':
case 'boltzman':
case 'hawking':
&alert_ldap_sysadmin();
# the mail systems. (that authenticate off of LDAP)
case 'feynman':
case 'faraday';
case 'curie':
case 'newton':
&alert_mail_sysadmin();
# helpdesk gets notified of everything not development
default:
&alert_helpdesk();
# development servers:
case 'teller':
case 'penn':
case 'houdini':
case 'copperfield':
&log();
}
Blah...submitted too early...anyway, the point is, that in that example, if 'einstein' is true, we alert management, ldap sysadmin, mail sysadmin, helpdesk, and it gets logged. (okay, I could've moved '&log' outside of the switch statement). But flow continues until there's a break...and in this case, there's no break. It gets even tricker when you have multiple paths like that through the system. (this was just ldap and mail servers... imagine if I add in web servers, and some of those webservers are also LDAP authenticating... okay, well, at that point, switch might not be so good for that one.... but we could alert the web admins as part of the ldap replica section, and then have a seperate section for the web servers.
I can do this in perl. (either using goto, or by using much more complicated lookup tables to tell how things propogate ... which may be needed, as the rules for notification can't be flattened to one dimension) | [reply]
[d/l] |
| [reply] |