Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:73732 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 93514 invoked from network); 17 Apr 2014 20:37:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Apr 2014 20:37:31 -0000 Authentication-Results: pb1.pair.com header.from=leight@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=leight@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.48 as permitted sender) X-PHP-List-Original-Sender: leight@gmail.com X-Host-Fingerprint: 74.125.82.48 mail-wg0-f48.google.com Received: from [74.125.82.48] ([74.125.82.48:55769] helo=mail-wg0-f48.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2B/90-23494-A8B30535 for ; Thu, 17 Apr 2014 16:37:30 -0400 Received: by mail-wg0-f48.google.com with SMTP id l18so899388wgh.31 for ; Thu, 17 Apr 2014 13:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=XLJZIU7KyJ0018ACMU8KZ7GzFsL+VJmIu8SMebCCP0s=; b=cqkyXPib8KXr0QMVIY1ve5Ef6S3V8/xtFxim0nZmy6s4cpIHUYUlCVeOXBtIRIcJhl vLB1MPQx3nR+pXqX8fDs+Nkm02OSUUPlTZYdCvTIDemkFFX8UKP7NcwpAP2yQJZ2ZSou gkn6Zb5hFWOnwPvURd9RpHoKUI3kEy3iD1bNzuzxzDsD9CNiZccmW/rYanYWPp1tq9Xu 7I6eH+PIAPkqE+/6E9yAgDLq22lsUgz8Sgo4yTZhcvqQaWmguP+zDCykLvfK60gB58xs u4E3L9Y4v4JVyGF/DxTVeuGmA9ouebHWVoAVLXseeX23kxO0vjE4tmU1qFcf92d9wB8g UeFg== MIME-Version: 1.0 X-Received: by 10.194.19.161 with SMTP id g1mr13474136wje.20.1397767047669; Thu, 17 Apr 2014 13:37:27 -0700 (PDT) Received: by 10.217.122.142 with HTTP; Thu, 17 Apr 2014 13:37:27 -0700 (PDT) In-Reply-To: References: <1397744009.2829.3212.camel@guybrush> <1397747255.2829.3225.camel@guybrush> <534FF26E.6070602@lerdorf.com> <838439B2-6179-4748-9EC1-525BF8D37072@seancoates.com> <534FFF3B.2020404@googlemail.com> <5350044F.40609@heigl.org> Date: Thu, 17 Apr 2014 21:37:27 +0100 Message-ID: To: PHP Developers Mailing List Content-Type: multipart/alternative; boundary=047d7b5d28585aee4a04f74300b6 Subject: Re: [PHP-DEV] Negative string offsets From: leight@gmail.com (Leigh) --047d7b5d28585aee4a04f74300b6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 April 2014 15:13, Johannes Schl=C3=BCter wro= te: > I'm +/-0 on this. But mind: Current form makes it simpler to find bugs > when miscalculating the offset. Allowing negative offsets gives harder > to debug results. Additionally I wonder how often this is actually > needed, thus justifying to change the language rules. I really don't know how often it would be needed, the patch comes from my own selfish reasons. I needed it today so I knocked something up. (I was dealing with string padding). We already have functions that accept negative offsets to produce similar behaviour, so I thought it might fit in. If the consensus is that it does not fit, then I'm happy to leave it at that. On 17 April 2014 14:11, Christian Stoller wrote: > > Generally I like this, but I think it's confusing and inconsistent in > comparison to array-indiexes, as you can have an array like `array(-1 =3D= > > 'foo')` I'm with Daniel on this one, I'd trust developers to know when they are dealing with a string or an array. On 17 April 2014 17:48, Daniel Macedo wrote: > I warned this would lead to the Python syntax... Of course, this is the php-bikeshedding list. I have to wonder though, do I take this as "full python compat or gtfo", or just ignore it, and hope for some actual responses on the issue under discussion. On 17 April 2014 19:13, Arvids Godjuks wrote: > > Although the syntax and ability is for the most part usefull, people forg= et > the unicode problem. > What should we let it traverse? Bytes or characters? Right now it is byte= s, > but it is rarelly used and people use functions and mb_* for unicode. > > This can be discussed only when we have full unicode, before that it is > useless and just generates a ton of problems and takes time implementing > from other more usefull stuff. > > A giant -1 from me. What unicode problem? The proposed behaviour is the same as is currently implemented. Not sure why you think string offsets are rarely used, my experience is exactly the opposite. I'm just going to go ahead and assume you think this thread is about python-style slice syntax. It is not. --047d7b5d28585aee4a04f74300b6--