in reply to Re7: OO style: Placement of "new"
in thread OO style: Placement of "new"

Ahh ... the old "I've-never-seen-it-fail-so-it-can't-fail" argument. Reminds me of the recent poll regarding favorite logical fallacies. I think I would've voted for this one. Arguing from personal experience is one of the worst arguments one can make, primarily because it's so seductive and it's almost valid.

The sentiments you express are exactly what I found troubling in merlyn's and Abigail II's remarks, which amounted essentially to the overwhelming two-part argument: "I have seen this not work, therefore you shouldn't use it". Well for a lot of people it does work, and my point is that we ought to figure out how to make it work even in these rare cases where people get bitten or at least work to increase understanding of its limitations.

While I might recommend that a newbie be careful when using indirection notation my own experience with it has been positive, and you can throw as many merlyn's and Abigails and Larry Wall's at me as you want but their mere luminescence is not an argument. To repeat dragonchild: I never claimed that these problems were not real, only that an outright ban was unnecessary, so kindly keep your flaming to yourself and don't lecture me on argumentation when you clearly haven't paid any attention to what my argument actually is.

"The dead do not recognize context" -- Kai, Lexx

Replies are listed 'Best First'.
Re9: OO style: Placement of "new"
by dragonchild (Archbishop) on Apr 08, 2003 at 19:19 UTC
    "I have seen this not work, therefore you shouldn't use it".

    Ummm ... that is a good argument as to why one shouldn't use a deprecated synactic construct which has the possibility of breaking previously-working code for unrelated reasons.

    The point is that code should be as bullet-proof as possible. Rearranging the order of module inclusion should never break anything. Ever. Period. If, by using DO vs. IO syntax, I can mathematically prove that rearranging said order will not break my code and I can mathematically prove that it will by using IO ... it seems to me that it's a no-brainer.

    Now, this argument may not be as critical to you, depending on the size and complexity of the applications you work with. In my opinion, once you get beyond, say, 10 minutes of explanation to a competent new-hire - that's when IO just shouldn't be used. Otherwise, it probably won't matter. (But, I'm not going to bet my money on that "probably" and anyone who bets their employer's money on that is, in my opinion, irresponsible.)

    ------
    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.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

[reply]

In Section Seekers of Perl Wisdom