Re: [development] the time of $op is over?
----- "Larry Garfield" <larry@garfieldtech.com> wrote:
I have an irrational hatred of switch statements, so eliminating hooks that are nothing but nested switch statements half the time gets a big +1 from me. :-)
I avoid them, too. But I have what I consider rational reasons: * Converting switch statements into more complex conditions is difficult. They require refactoring, which is often a source for errors. If I use if/else, then I only have to worry about refactoring if the logic structure truly changes. Anticipation of change is the same reason we require braces for even one-line conditionals: expanding a one-line conditional that lacks braces is more error-prone. * Lack of break statements is a common source for errors. * With a combination of break statements and fall-through switches (intentional lack of breaks between cases), it can be difficult to quickly understand control flow. Unlike for if/else structures, control does not follow indentation. * A long series of cases is often justification for reconsidering the program structure, like we are right now with $op. Frankly, the best thing switch has going for it is rather simple conversion to assembly in lower-level languages like C++. The switch functionality is directly derived from "branch if equal" instructions, and break is directly derived from "branch unconditional" instructions.
----- "David Timothy Strauss" <david@fourkitchens.com> wrote:
* With a combination of break statements and fall-through switches (intentional lack of breaks between cases), it can be difficult to quickly understand control flow. Unlike for if/else structures, control does not follow indentation.
Whoops, I meant "fall-though cases."
The $op is relatively easy to understand but clunky to use. So I would certainly find individual hooks/functions for each one of the states a cleaner way to do things. How complicated would it be to move to a true event-based model, where modules register as listeners to events and respond to them rather than hook in through functions that have the right names? I was thinking that a structure similar to menus would be nice and would replicate ideas from other parts of Drupal meaning that newcomes have fewer concepts to learn. A module registers to an event/hook the same way it relates a URL to a callback function and the callback function is where the module performs actions related to that event. Best, Ronald On Tue, May 13, 2008 at 7:45 AM, David Timothy Strauss < david@fourkitchens.com> wrote:
----- "David Timothy Strauss" <david@fourkitchens.com> wrote:
* With a combination of break statements and fall-through switches (intentional lack of breaks between cases), it can be difficult to quickly understand control flow. Unlike for if/else structures, control does not follow indentation.
Whoops, I meant "fall-though cases."
On 13 May 2008, at 9:55 AM, Ronald Ashri wrote:
How complicated would it be to move to a true event-based model, where modules register as listeners to events and respond to them rather than hook in through functions that have the right names? I was thinking that a structure similar to menus would be nice and would replicate ideas from other parts of Drupal meaning that newcomes have fewer concepts to learn. A module registers to an event/hook the same way it relates a URL to a callback function and the callback function is where the module performs actions related to that event.
isn't that what the function registry does ?
Quoting David Timothy Strauss <david@fourkitchens.com>:
* A long series of cases is often justification for reconsidering the program structure, like we are right now with $op.
You don't have to use a switch statement now nor long complicated if/elseif/else statements either. <?php $func = '_mymodule_func_' . $op; if (function_exists($func)) { $ret = call_user_func_array($func, $args); } ?> Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Hi, On 13/05/2008, at 10:01 PM, Earnie Boyd wrote:
Quoting David Timothy Strauss <david@fourkitchens.com>:
* A long series of cases is often justification for reconsidering the program structure, like we are right now with $op.
You don't have to use a switch statement now nor long complicated if/ elseif/else statements either.
<?php $func = '_mymodule_func_' . $op; if (function_exists($func)) { $ret = call_user_func_array($func, $args); } ?>
Yes this is good, and make the code simplier. I actually removed $op from e-Commerce where ever I found it. Tidied things up very well. Gordon.
On Tue, 13 May 2008 22:55:08 +1000, Gordon Heydon <gordon@heydon.com.au> wrote:
Hi,
On 13/05/2008, at 10:01 PM, Earnie Boyd wrote:
Quoting David Timothy Strauss <david@fourkitchens.com>:
* A long series of cases is often justification for reconsidering the program structure, like we are right now with $op.
You don't have to use a switch statement now nor long complicated if/ elseif/else statements either.
<?php $func = '_mymodule_func_' . $op; if (function_exists($func)) { $ret = call_user_func_array($func, $args); } ?>
Yes this is good, and make the code simplier. I actually removed $op from e-Commerce where ever I found it.
Tidied things up very well.
Gordon.
Agreed. My code is littered with dynamic subcalls like that for everything from eliminating op to having a per-node-type preprocess function. It makes the code far easier to follow and maintain. Building that or something like it straight into most subsystems is a good thing. --Larry Garfield
participants (6)
-
Adrian Rossouw -
David Timothy Strauss -
Earnie Boyd -
Gordon Heydon -
Larry Garfield -
Ronald Ashri