1. Certainly. A plugin system for a program comes to mind immediately, where plugins are modules with a specific interface and are added simply by dropping them in a directory.

    "Why would anyone want to do X?" is never a good reason to advise against it. If you can say "almost all the people who do X suffer Y" then you do have a case. I am reminded of my recent rereading of Mark-Jason Dominus' Critique of the Perl 6 RFC Process; specifically, this passage:

    People would frequently send me mail asking me to add a certain feature, such as timed expiration of cached data. I would reply that I didn't want to do that, because it would slow down the module for everyone, and it would not help the next time I got a similar but slightly different request, such as a request for data that expires when it has been used a fixed number of times. The response was invariably along the lines of "But what would anyone want to do that for?" And then the following week I would get mail from someone else asking for expiration of data after it had been used a fixed number of times, and I would say that I didn't want to put this in because it wouldn't help people with the problem of timed expiration and the response would be exactly the same.
  2. Which way I'll answer depends on how much information the poster gives. If I can clearly see that he's getting himself into trouble, I'll point out that it shouldn't be done this way first and explain why, and then add the solution requested merely as a point of interest, hoping that the poster will learn how to do what he wanted while steering clear of that solution for the case he asked about. If there isn't that much information, or if it isn't clearly a bad idea but just could be done better, then I'll answer the question and add a few words on the advantages of doing it another way. If I can only suspect that a certain bad idea is the motivation, then along with the answer to the question I might add something along the lines of "you're not trying to do X, are you? if so, then you shouldn't, do Y instead" or ".. if so, then we can probably point out a better way if you give us more information".

Makeshifts last the longest.


In reply to Re: Being helpful to a fault? by Aristotle
in thread Being helpful to a fault? by graff

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.