in reply to Re^5: Moose and caller() for current method
in thread Moose and caller() for current method

Wrong IMHO. You have no context of my implementation to immediately assume from my simplified question that I am in fact creating spaghetti code. This is a dispatch table that fires automagic evaluation of parameters when executing a specific action in a pseudo-worflow logic. Method (action) names are fixed and they are dependent within a tight group of classes which conform the super-simple Workflow engine, that I have crafted to be compatible to CPAN Workflow, in case I want to substitute that part in the future.

The reason why I use and love Perl is to have the freedom to combine programming styles without being Dogmatic about any specific one. I don't see the evils of runtime introspection nor do I fully understand the rant on "Modern Perl", and what it has to do my OP. I admit my ignorance in Moose and only use it to keep with the general style of Catalyst these days, but it's still Perl, so why be so religious to OO? For that matter you should be also ranting out "Advanced Perl Programming" and "Higher Order Perl", just to name a couple.
  • Comment on Re^6: Moose and caller() for current method

Replies are listed 'Best First'.
Re^7: Moose and caller() for current method
by BrowserUk (Patriarch) on Jul 18, 2010 at 17:50 UTC
    You have no context of my implementation to immediately assume ... that I am in fact creating spaghetti code.

    Sorry. But when you said:

    it is useful to know the action being executed to validate for certain parameters to execute that action.

    you gave me that context.

    A subroutine or method that needs to know where it is called from, in order to validate its arguments, *is* spaghetti code.

    It means that each time you need to call that subroutine from a new piece of code, you have to modify the subroutine to handle the new caller. And that type of codependency-at-a-distance is the modern reincarnation of spaghetti coding.


    And for the record, as anyone familiar with my writings here will confirm, I'm not at all religious about OO. Indeed, I'm kinda known for railing against the dogmatic overuse of OO.

    Nor am I religious about any other particular coding methodology. OO, used appropriately and correctly, is just another tool in the coders toolbox. Along with FP, and procedural, and event driven and any other you care to name.

    But there are certain fundamental principles in coding that hold true across all coding styles, and loose coupling is one such.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.