|
in reply to Re^3: Moose and caller() for current method
in thread Moose and caller() for current method
Not quite the only good reason. In building something like a simple FSM it is useful to know the action being executed to validate for certain parameters to execute that action. This could be set by the calling sub as a parameter or the called sub to introspect. I'm thinking it should be the called sub instead of what I'm trying to do, but want to use Moose's best practices. |
Re^5: Moose and caller() for current method
by BrowserUk (Patriarch) on Jul 13, 2010 at 18:54 UTC
|
it is useful to know the action being executed
Useful to whom? Cos code doesn't give a toss what it is called; or even if its caller has a name.
If you are writing subroutines that do different things dependant upon where they are called from, you've completely missed the point of OO, encapsulation and even structured programming.
You are violating the first principle of reusable encapsulation--Loose coupling--by building in tight dependency by design. In other words, you've re-invented spaghetti code.
This current fad for runtime introspection is the single biggest backward step in programming in the last 30 years.
"Modern Perl" be damned. It is nought more than another attempt to introduce programming by rote. But like painting by numbers, it is never going to produce works of art; nor even practical craft.
It's the new "New Math". And history shows what happened to that.
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.
| [reply] |
|
|
| [reply] |
|
|
| [reply] |
|
|
|
|
| |
|
Modern Perl" be damned. It is nought more than another attempt to introduce programming by rote.
Completely agreed. But some people learn by rote, and it's better to teach them a more robust rote than before.
But like painting by numbers, it is never going to produce works of art
Agreed. But even artists need to have tools, and learn about them
nor even practical craft
Depends on what you mean by "modern Perl". For me, "modern Perl" includes simple advice like "use 3-arg open". That certainly leads to practical craft.
Perl 6 - links to (nearly) everything that is Perl 6.
| [reply] |
|
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
