|
in reply to Re^2: defining methods on the fly
in thread defining methods on the fly
Don't lose sight of the fact that the OP was unabashedly admitting that 'good programming practices' were being ignored in favor of the 'coolness' of the idiom. That's where I draw the line -- use all the expressive power of Perl you like, but do it consistently and carefully and, for crying out loud, thoroughly comment anything that is especially clever, elegant or obscure. I've had several occasions to bewail the unnecessary complexity of some code I had to maintain, only to discover that it was something I wrote (in one case, only a few months before).
No good deed goes unpunished. -- (attributed to) Oscar Wilde
|
Re^4: defining methods on the fly
by BrowserUk (Patriarch) on Aug 03, 2006 at 14:36 UTC
|
What the OP actually said is
I['m] sure this breaks some rules of good programming practice,
Which reads to me a little like someone saying "I'm sure that it will offend someone somewhere for me to say this, but I really enjoyed the dog stew I was served in Cambodia"*.
Given that site:cpan.org autogenerate methods a very quick query of CPAN shows up a large number of modules that either autogenerate methods for their own use, or provide the facility of autogenerating accessors and mutators for use by other class modules. And that many of these are written by some of Perl's biggest and most respected names. The basic idea is far from a uniquely obscure, dangerous or obviously "bad practice".
Indeed, there is a strong argument that one of the major benefits of using a dynamic language is the ability to write code that generates code. This is epitomised by the Once And Only Once practice design principle of XP fame and was (I think) originally advocated in the book, The Pragmatic Programmer: From Journeyman to Master, which is generally very highly regarded.
Without critiquing the OP's implementation, the basic idea is far from a "bad programming practice", and it is anonymonk's somewhat kneejerk reaction to the OP's use of the word "cool" that I was addressing.
*I've never been to Cambodia!
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply] |
|
|
I don't think I'm qualified to judge this specific implementation, or to weigh in on a particular 'good programming practice'. I was reacting to what I perceived as your er, kneejerk reaction, in seeming to generally defend 'cool' Perl idiom.
I think you expressed your point of view well, when you indicated that resistance to a particular Perl idiom can be rooted in individual unwillingness to learn more Perl. But I think it is common for Perl developers to indulge their taste for the elegant at the expense of code clarity or maintainability, a natural pitfall of TIMTOWTDI. It may have been unfair for anonymonk to pick on the OP in this particular instance, but I don't think I am alone in wishing that some of the 'cute' idioms could be restrained so that those of us (I admit it freely) who haven't yet learned all of Perl could get on with our work.
I know I'm out of my depth in arguing with you, and I hope I'm not just trying to have the last word, but I feel a little like George Bailey in It's a Wonderful Life, when he says to Mr. Potter, "They may be 'rabble' to you, but this 'rabble' you sneer at does a lot of the living and working and dying in this town. Is it too much to ask that they do that living in two rooms and a bath?" (original quote badly paraphrased).
| [reply] |
|
|
I don't think I am alone in wishing that some of the 'cute' idioms could be restrained so that those of us (I admit it freely) who haven't yet learned all of Perl could get on with our work.
In what sense do they prevent you from doing your work?
If you have another developer on your team who persists in using idioms you don't understand, either ask for help learning the idiom and decide if it's worth using, or, as a team, decide not to use that idiom. (If you can't do either, your code maintenance problems have very little to do with technology.)
| [reply] |
|
|
|
|
|
|
| [reply] |
Re^4: defining methods on the fly
by flogic (Acolyte) on Aug 03, 2006 at 15:07 UTC
|
Well the question is more which practices does it ignore and in this case does it pay off? Personally I think it may well pay off so I'm using it. | [reply] |
|
|
