git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Witten <mfwitten@gmail.com>
To: Jay Soffian <jaysoffian@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH RFC3.5 08/12] send-email: Move Subject sanitization from  --compose code to send_message
Date: Sun, 19 Apr 2009 09:53:47 -0500	[thread overview]
Message-ID: <b4087cc50904190753v6f5862c0sebe2dcc56c5269dc@mail.gmail.com> (raw)
In-Reply-To: <b4087cc50904190739u54a9a9d7p6f011ab2b47c1d05@mail.gmail.com>

On Sun, Apr 19, 2009 at 09:39, Michael Witten <mfwitten@gmail.com> wrote:
> I'm morally opposed to this kind of thing. The caller should be
> required to test whether quote_rfc2047() is required, as it's not the
> job of quote_rfc2047 to validate. Suppose that quote_rfc2047 were
> actually part of a library of useful functions that my program
> imports. Perhaps my program knows that it must always quote some piece
> of text. Why, then, should my program be forced to waste the cycles to
> perform a useless test?
>
> IMnsHO, verification should always be done by the caller with one
> exception: Interactive (human) input should always be verified,
> because humans represent an unreliable component in the system (in
> terms of digital systems, their asynchronous input must be
> synchronized with the clocked system). WIth this model, there's are
> fewer wasted cycles, because you can reuse verification across similar
> functions, and the code (particularly library code) is easier to
> understand.

I should add, though, that making the logic of the program clear is a
good idea. In that sense, your approach makes sense. Since we 'own'
quote_rfc2047(), I'd say we could take your approach, but rename the
function to something like quote_rfc2047_if_necessary(). If
quote_rfc2047() were part of a library, I think the only moral
solution would be to insist that callers wrap it in another function
named quote_rfc2047_if_necessary().

  reply	other threads:[~2009-04-19 14:55 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-18 17:01 [PATCH RFC3.5 00/12] Introduction to Decreasing send-email Entropy Michael Witten
2009-04-18 17:01 ` [PATCH RFC3.5 01/12] send-email: Cleanup the usage text and docs a bit Michael Witten
2009-04-18 17:01   ` [PATCH RFC3.5 02/12] send-email: No longer repeatedly test if $smtp_server is a command Michael Witten
2009-04-18 17:01     ` [PATCH RFC3.5 03/12] send-email: Interpret --smtp-server "" as "use a default" Michael Witten
2009-04-18 17:02       ` [PATCH RFC3.5 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-18 17:02         ` [PATCH RFC3.5 05/12] send-email: Improve redability and error-handling in send_message's sendmail code Michael Witten
2009-04-18 17:02           ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Michael Witten
2009-04-18 17:02             ` [PATCH RFC3.5 07/12] send-email: Cleanup send_message 'log' code Michael Witten
2009-04-18 17:02               ` [PATCH RFC3.5 08/12] send-email: Move Subject sanitization from --compose code to send_message Michael Witten
2009-04-18 17:02                 ` [PATCH RFC3.5 09/12] Docs: send-email: Reorganize the CONFIGURATION section Michael Witten
2009-04-18 17:02                   ` [PATCH RFC3.5 10/12] Docs: Embolden the CONFIGURATION references Michael Witten
2009-04-18 17:02                     ` [PATCH RFC3.5 11/12] Docs: send-email: Clarification of sendemail.<identity> Michael Witten
2009-04-18 17:02                       ` [PATCH RFC3.5 12/12] Docs: send-email: git send-email -> 'send-email' Michael Witten
2009-04-19  1:54                 ` [PATCH RFC3.5 08/12] send-email: Move Subject sanitization from --compose code to send_message Jay Soffian
2009-04-19  2:37                   ` Michael Witten
2009-04-19 14:13                     ` Jay Soffian
2009-04-19 14:39                       ` Michael Witten
2009-04-19 14:53                         ` Michael Witten [this message]
2009-04-19 16:43                         ` [PATCH RFC3.5.1 08/12] send-email: Simplify --compose subject sanitation Michael Witten
2009-04-21  2:34                           ` Jeff King
2009-04-21  3:29                             ` Michael Witten
2009-04-20  1:42             ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Junio C Hamano
2009-04-20  5:38               ` Michael Witten
2009-04-20  6:43                 ` Junio C Hamano
2009-04-19  1:51           ` [PATCH RFC3.5 05/12] send-email: Improve redability and error-handling in send_message's sendmail code Jay Soffian
2009-04-19  2:13             ` Michael Witten
2009-04-19  2:17               ` Thomas Adam
2009-04-19  2:43                 ` Michael Witten
2009-04-19  4:44                   ` Junio C Hamano
2009-04-19 13:49                     ` [PATCH RFC3.5.1 05/12] send-email: Improve readability " Michael Witten
2009-04-19 14:16                 ` [PATCH RFC3.5 05/12] send-email: Improve redability " Jay Soffian
2009-04-20  1:38           ` Junio C Hamano
2009-04-20  1:58             ` Junio C Hamano
2009-04-21  2:00               ` Jeff King
2009-04-21  3:14                 ` Jeff King
2009-04-19 14:19         ` [PATCH RFC3.5.1 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-20 15:53           ` Michael Witten
2009-04-20  1:42         ` [PATCH RFC3.5 " Junio C Hamano
2009-04-20  2:38           ` Junio C Hamano
2009-04-20  3:49             ` [PATCH RFC3.5 06/12] send-email: Cleanup and streamline the SMTP code in send_message Michael Witten
2009-04-20  3:49             ` [PATCH RFC3.5 04/12] send-email: Verification for --smtp-server and --smpt-server-port Michael Witten
2009-04-18 23:35       ` [PATCH RFC3.5 03/12] send-email: Interpret --smtp-server "" as "use a default" Wesley J. Landaker
2009-04-19  0:13         ` Michael Witten
2009-04-19 14:16           ` [PATCH RFC3.5.1 " Michael Witten
2009-04-20  1:41       ` [PATCH RFC3.5 " Junio C Hamano
2009-04-20  2:52         ` Michael Witten
2009-04-20  1:41     ` [PATCH RFC3.5 02/12] send-email: No longer repeatedly test if $smtp_server is a command Junio C Hamano
2009-04-20  2:37       ` Michael Witten
2009-04-20  4:21         ` Junio C Hamano
2009-04-20  4:53           ` Subject: " Michael Witten

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b4087cc50904190753v6f5862c0sebe2dcc56c5269dc@mail.gmail.com \
    --to=mfwitten@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=jaysoffian@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).