Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:38063 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 83721 invoked from network); 1 Jun 2008 21:30:28 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 1 Jun 2008 21:30:28 -0000 Received: from [127.0.0.1] ([127.0.0.1:18622]) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ECSTREAM id 18/38-35077-4F413484 for ; Sun, 01 Jun 2008 17:30:28 -0400 X-Host-Fingerprint: 83.6.228.160 abcm160.neoplus.adsl.tpnet.pl Received: from [83.6.228.160] ([83.6.228.160:11196] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CD/52-54820-3D492484 for ; Sun, 01 Jun 2008 08:23:50 -0400 Message-ID: To: internals@lists.php.net Date: Sun, 01 Jun 2008 14:23:40 +0200 References: <0412F6FE505049F7901EAB8C61774839@pc> <1212087326.20983.22.camel@goldfinger.johannes.nop> <1212097521.2979.11.camel@goldfinger.johannes.nop> <50.44.55660.02A20484@pb1.pair.com> <1212236851.8837.0.camel@localhost> <1212251610.8837.14.camel@localhost> Lines: 47 Organization: CrystalPoint User-Agent: KNode/0.10.5 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Posted-By: 83.6.228.160 Subject: Re: [PHP-DEV] Re: Short syntax for array literals [...] From: m.kurzyna@crystalpoint.pl (Marcin Kurzyna) Lars Strojny wrote: >> Not like they will be listened to unless they are "commiters". > > They are heard. The issue is, as always in programming, you want to do [...] > maintainability, safety and security. I'm not saying the core > contributors are always right, but there being core contributors is an > evidence. Yes, but in this and some other cases (i've been reading internals for quite some time now) it's just a question of wether the majority with karma likes or dislikes (as in i like yellow more then red) certain feature. The short array syntax isn't a technical issue or dificulty as was discussed and acknowledged. It wasn't ment to replace explicit array() nor does't it impose noticable performance loss. And it's not like there wasn't a will to write a patch as in some other cases - it's just a metter of maitanance when the 'commiters' in general don't like it (as noted in conclusion in wiki). So in the end it's just a matter of veto power of those with karma over those without. Which is (in most cases) the right way to go as illustrated by the Company Argument. What i don't understand is why sutch a non intrusive feature had to go through sutch passionate discussion and voting process. There are commiters who like it (more then one) and probably could maintane it (i guess it wouldn't be mutch work as it's mostly a one time parser change binding to already existing and maintained functionality; though i might be wrong here). If so why couldn't this go in and just be ignored by those who don't like it? It's not like anything wolud change for them. Any way - it's just my thoughts and as the proposal was already declined i don't see mutch more reason for discussion. I think it will come back in couple months again though as most things with out really clear consensus. m. ps. it polite to say hi when entering a room, so: hi. -- Marcin Kurzyna - Software Engineer @ CrystalPoint here as "a voice from userland developers(tm)"