Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91211 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 98736 invoked from network); 11 Feb 2016 18:07:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 11 Feb 2016 18:07:20 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.179 as permitted sender) X-PHP-List-Original-Sender: smalyshev@gmail.com X-Host-Fingerprint: 209.85.192.179 mail-pf0-f179.google.com Received: from [209.85.192.179] ([209.85.192.179:36696] helo=mail-pf0-f179.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2A/BD-25203-7DDCCB65 for ; Thu, 11 Feb 2016 13:07:20 -0500 Received: by mail-pf0-f179.google.com with SMTP id e127so33081714pfe.3 for ; Thu, 11 Feb 2016 10:07:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=8HDyypVamZvJqt32OOwakRFsQJYpKoIxNZNmKmJ9AHU=; b=UsLkqKluTBQNv4sMxgoIX1j7GBPZTHzwliUOT0NdOJ2hiB4Si0wnaZtkxhkhjLn9or NX6YWvAeORtWcDmEdmDzbZqnKpr9npuTHZQbr1g8U5EVBoogwZyyRxOAz4mJul82Bnct SA4IRKLffrN4ldrSnZHXgiPcww5QJ7WMP0vOiN5Srer5FSGZKc5QB+wCEZuMTkA/+IQu VMUnGH7K5WecSBe+nmP6yTQFa5y3gG08yh15JGLW2d0t/88JpEAGaTuVfF4az2XNvUGR 4/4drm0Ow9R6dtvVQzJap0B8B6WUQGld4C0TVeG56FHwkkGKm0+L5jMUHm5X5sVX3j9n iV7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=8HDyypVamZvJqt32OOwakRFsQJYpKoIxNZNmKmJ9AHU=; b=I9+EyT8yTWo7C2kMcIoUJ3lLV4zZJCnLWxSXI7cOLMQUzOqPBBAhY43OqUL1PSheaC lX7jx/O6VlKM1ffEgnau1SFfcz489OrgMwm9kh7XFZldvSuU+ue1Hxs3awQ2B9jKrsFz EpMNBCUX6dQNn1NYSbcsfjXHyk6qBUwajNQitAs5Wi/TR1jlyxQbh1WCiJtiInDnLM7s jF0wxwZD2BGP2gqc/4cQWek568Fs9nyKyPWpizjuTuhiOdAIembQPcTr4+1E42qfpQUi 5bQl+SCyL2K8Jy6+6gj+A5VM4L/hvB/8hW07ap/0/Y8MyatqDWM7dYybx94+8TK/Efv0 hLiw== X-Gm-Message-State: AG10YOTn9NT+XIzPbkHl8cOw5VWfjfe2xRZkfqZv4Cjas0eOvXU1heDcNBSiBxPnnxp5pQ== X-Received: by 10.98.80.135 with SMTP id g7mr68893126pfj.132.1455214037239; Thu, 11 Feb 2016 10:07:17 -0800 (PST) Received: from Stas-Air.local (tan1.corp.wikimedia.org. [198.73.209.1]) by smtp.gmail.com with ESMTPSA id f21sm13839018pfd.6.2016.02.11.10.07.15 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 11 Feb 2016 10:07:16 -0800 (PST) To: Yasuo Ohgaki References: <56A3A01F.1020500@php.net> <56BB4A5F.3060906@php.net> <56BC29C8.9070308@gmail.com> <56BC3372.1010308@gmail.com> Cc: =?UTF-8?Q?Fran=c3=a7ois_Laupretre?= , Internals X-Enigmail-Draft-Status: N1110 Message-ID: <56BCCDD3.8030402@gmail.com> Date: Thu, 11 Feb 2016 10:07:15 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Generalize support of negative string offsets From: smalyshev@gmail.com (Stanislav Malyshev) Hi! > Anyway, all of us know that main source of complaints about PHP is lack > of consistency. Inconsistent APIs across modules are acceptable. It's > modules after all. However, basic language constructs like [] and {} are > better to have predictable/consistent behaviors. i.e. how it works, raised > errors. They do have predictable behavior. Again, "consistent" here does not have any defined meaning as far as I can see, given how many people use it to mean so many different things. It became sort of a shortcut - instead of explaining why the change is good, you just say "for consistency" and expect everybody to nod and agree. I don't think it works. > This RFC improves inconsistent behaviors a lot. Why not to add > $str{} = 'string'? It's not complex nor BC as it raises syntax error currently. Because it is not needed and it is an unnecessary weird syntax for the operation we already have a syntax for - string concatenation. Moreover, it borrows syntax from another operation - string offset - while doing totally different thing ($a{1} = 'foo' would only use one character - 'f', but $a{} = 'foo' would use the whole string, right?). Moreover, while there is a practical need in string offsets (though I would say making them writable is a bit questionable) there is no need to invent syntax for concatenation, we already have it. > It does not worth the effort having other RFCs for > - $str{} = 'string' Correct, because nobody needs it and it is a bad idea. > I agree small changes are easier to review, but it may leave lots of > obvious inconsistency in PHP. We have too many of them already. If you have examples of "obvious inconsistency", name them and we will discuss it. {} is not such example. > Making RFC and pass the vote is not easy task. Authors may not have > time for RFCs for clean ups. Understandable, not everyone has time to contribute to PHP. Those who have the time, do, and we are grateful to them. However, if somebody doesn't have the time, that is not the reason to lower our standards. -- Stas Malyshev smalyshev@gmail.com