in reply to Re: (ichimunki) Re x 3: Thoughts on Perl6 - Love it? Hate it?
in thread Thoughts on Perl6 - Love it? Hate it?

Your example methodology adds not one, but two layers of indirection to what is otherwise a straightforward question-- and gets none of the fall through capability of the typical switch statement at the same time. It is therefore less than optimal in situations where switch is designed to be most used.

The one place your indirect method absolutely shines is when you want to set up a mutating hash of anonymous subs (the dispatch table essentially). You keep your condition tree static perhaps (or the condition tree could be just another dispatch (or dispatches!) in the dispatch table). Then you can swap different subs in an out for the same results/conditions labels. Although I'd have to wonder if you can do this for any non-trivial, non-proof of concept application and maintain your sanity or the application later. *grin*
  • Comment on (ichimunki) Re x 5: Thoughts on Perl6 - Love it? Hate it?

Replies are listed 'Best First'.
(dragonchild) Re x 6: Thoughts on Perl6 - Love it? Hate it?
by dragonchild (Archbishop) on Jan 11, 2002 at 20:28 UTC
    No, I don't have the fall-through capability, natively. One would have to have the functions themselves call each other to gain fall-through. (If 'A' would fall through to 'B', then A() does a return B(@_); at the end.) This is somewhat counter-intuitive and very tightly coupled, but it does have benefits.

    The primary benefit I see, apart from the dynamic nature of it, is that I can pass args to my switch clauses. In addition, I've separated out my switch clauses from one another, which means that they can be arbitrarily long and not go over-long within the same function.

    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.