Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73449 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56781 invoked from network); 27 Mar 2014 05:34:04 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Mar 2014 05:34:04 -0000 Authentication-Results: pb1.pair.com header.from=swhitemanlistens-software@cypressintegrated.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=swhitemanlistens-software@cypressintegrated.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain cypressintegrated.com designates 173.1.104.101 as permitted sender) X-PHP-List-Original-Sender: swhitemanlistens-software@cypressintegrated.com X-Host-Fingerprint: 173.1.104.101 rproxy2-b-iv.figureone.com Received: from [173.1.104.101] ([173.1.104.101:49851] helo=rproxy2-b-iv.figureone.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 53/E0-48757-A48B3335 for ; Thu, 27 Mar 2014 00:34:03 -0500 Received: from bad.dop.co ([108.12.130.219]) by rproxy2-b-iv.figureone.com (Brand New Heavy v1.0) with ASMTP id NII53554 for ; Wed, 26 Mar 2014 22:33:54 -0700 Date: Thu, 27 Mar 2014 01:33:58 -0400 Reply-To: Sanford Whiteman X-Priority: 3 (Normal) Message-ID: <823433806.20140327013358@cypressintegrated.com> To: "Bill Salak" In-Reply-To: <01bb01cf493d$5b78a660$1269f320$@devtemple.com> References: <010e01cf4788$05f3c5a0$11db50e0$@devtemple.com> <01c801cf47c0$59acbf20$0d063d60$@devtemple.com> <01bb01cf493d$5b78a660$1269f320$@devtemple.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] session_start(), read_only, lazy_write; Take 2 From: swhitemanlistens-software@cypressintegrated.com (Sanford Whiteman) > This is only 1 example that's analogous to opening a session as read > only Is it, though? Vim's read-only mode prevents you from silently saving changes to the original file, but it does not prevent you from saving changes once you confirm them. Vim ro is like session_start( read_only = true ) and then something like session_write_close( confirm_write = true ) -- an extra arg that forces you to confirm the write but allows you to do it if you insist, without manually reopening. Of course interactive warnings and unattended code can't really be compared. But the "continue, if you're sure" experience of Vim ro surely isn't the "start over, you screwed up" expected from read_only = true. > If I didn't know already, when presented with the option for > "read_and_close" I would probably have a minor wtf moment but it > *would* make me read the docs to understand what exactly it means to > me if I use it, since it's an unconventional option name. I think that you've made a ringing endorsement of an explicit, unambiguous name. No robust language can seek to be self-explanatory, but it can aim for clear, complete documentation. This term has multiple meanings that are all "mainstream"; debate about THE meaning is fruitless. IMO. -- Sandy