Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:20115 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 76229 invoked by uid 1010); 17 Nov 2005 23:53:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 76213 invoked from network); 17 Nov 2005 23:53:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Nov 2005 23:53:00 -0000 X-Host-Fingerprint: 66.11.173.122 unknown Received: from ([66.11.173.122:56304] helo=interjinn.com) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id 05/3C-07637-CD71D734 for ; Thu, 17 Nov 2005 18:53:00 -0500 Received: from blobule.suds (blobule.suds [192.168.1.3]) by interjinn.com (Postfix) with ESMTP id A286A11FB69; Thu, 17 Nov 2005 18:52:57 -0500 (EST) To: Ilia Alshanetsky Cc: Andreas Korthaus , Rasmus Lerdorf , internals@lists.php.net In-Reply-To: <1132271500.18353.53.camel@blobule.suds> References: <437B530A.5050105@prohost.org> <437CF6B4.5080207@web.de> <437CF943.7090800@lerdorf.com> <437D0D08.8060805@web.de> <437D0E22.7080006@lerdorf.com> <437D11B7.7090102@web.de> <437D1361.5080504@prohost.org> <1132271500.18353.53.camel@blobule.suds> Content-Type: text/plain Organization: InterJinn Message-ID: <1132271599.22860.0.camel@blobule.suds> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.5-4mdk Date: Thu, 17 Nov 2005 18:53:19 -0500 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] dropping curly braces From: robert@interjinn.com (Robert Cummings) On Thu, 2005-11-17 at 18:51, Robert Cummings wrote: > On Thu, 2005-11-17 at 18:33, Ilia Alshanetsky wrote: > > Andreas Korthaus wrote: > > > OK, but by dropping {} for strings you also remove the possibility to > > > have a convention like "[] for arrays and {} for strings". > > > If I could decide I would drop {} for arrays and [] for strings, but I > > > fear I will not be asked to decide... ;-) > > > > You may think that {} and [] are different, but in reality same code > > deals with both. Having two constructs for the same behavior is silly > > and leads to confusing, hard to read code. Especially so when you > > consider the fact {} has another meaning that is completely different. > > That should have been considered before everyone was told that [] was > deprecated for strings in favour of {}. Dropping support for string > access via {} is akin to slapping those who followed the lead. Once > bitten, twice shy. I don't see support for it falls under the exact same argument. But maybe there's a trend > emerging here, and in fact It's a tough call since credibility is rapidly swirling down the toilet. I just re-read what I posted, and it's a bit meaner sounding than I intended, but I'm sure you can understand the mounting frustration :| Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------'