Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52624
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type;
        b=GUdiSinfBS7aGoPG2+KlOqG9P4vqpuhWo6TR4zZBggS61KR31LrEVc88kKYuToImIK
         6G/ebWcpSlbDt4Ar2+6lQrOITpJOrhITPI5AkvBnMuFnm68CgmtWdUdFFy1I2zczPKjW
         aavZOVlSAdE8LYMzIPuYiVA5W9WQHrfy9rvrM=
MIME-Version: 1.0
In-Reply-To: <4DE5CAEA.4030805@sugarcrm.com>
References: <4DE5368A.6050603@moonspot.net>
	<2BFFEAC1-395E-4101-9452-002E63DCFD91@seancoates.com>
	<4DE55AB7.9050206@lerdorf.com>
	<4DE55CDA.302@sugarcrm.com>
	<BANLkTincn+xOppttU-mmwGycbz5dPon_vA@mail.gmail.com>
	<BANLkTinDk3YkJEBKeUSe_4og2NSY9rayxw@mail.gmail.com>
	<4DE5666A.3080506@lerdorf.com>
	<BANLkTi=F4SdC0DCG1ec6EQSYpoonFX58UA@mail.gmail.com>
	<4DE5CAEA.4030805@sugarcrm.com>
Date: Tue, 31 May 2011 22:35:40 -0700
Message-ID: <BANLkTin+i7W-6uCOPVdoK1rgr0KaXGX6rw@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
From: mike503@gmail.com (Michael Shadle)

I don't really want to stand on my soapbox any longer, as it's obvious
where the crowd leans on this one, but I need to clarify a couple
points a bit and feel obligated to reply to another.

On Tue, May 31, 2011 at 10:15 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:

> Fundamental changes means "throw out your production code and start
> developing a new one". Guess how many PHP shops with existing code would be
> happy to do it. It's nice to rant about how PHP function are inconsistent
> and stuff, but no project was seriously impeded by it ever. At most it is
> mildly irritating. Huge BC break, on the other hand, would mean all major
> apps/libraries/frameworks become instantly not available, and who knows when
> they catch up. At this point, you might as well have a new language.

This is understood, but it was a crackpot example. IMHO, adding more
ways to express the same thing in a well-established language is more
or less the same. It's relearning something you thought you already
knew; yes, one breaks BC, but that is why you'd have to classify it a
different major version. I'm done on that one. Like I said, it's a
crackpot example.

> Since many experienced people are supporting it, I'd think that while it
> seems unnecessary to you, it may seem otherwise for them.

Many experienced people are also against it.

If a handful of "experienced people" decided to go forward with my
crackpot idea above, would you be in support, just because they are?

Also, you're implying that this is a *necessary* change for these
experienced people. Is there something I am missing that PHP is *not*
handling currently and requires this *necessary* change? (No)

> Read this (esp. first answer):
> http://stackoverflow.com/q/6162484/214196
>
> It's about Perl, but gives you an impression why it is so tough.

I figured it was tough, based on the amount of effort/time people
spent. Sad to see that it seems abandoned though.

> Why not? If the pieces are good, stealing them is good. It's how progress
> happens - you "steal" good pieces and add couple of your own, and hope the
> result is good enough that somebody else would want to steal stuff from it

While a language is maturing, I would probably agree. I consider PHP
quite mature now. I'd say the proof is in the pudding based on the
numbers.

My chief concerns are these:

IMHO, JSON-style syntax is *not* as readable as PHP array syntax. It's
shorthanding something that is pretty short as well.

Currently, if I want to find an array in code, I can search just for
"array" or "Array" or "=>" or variations thereof. This adds yet
another type of grep I have to run through. One that I am not sure can
be easily accomplished (wouldn't it be matching quite a lot more
because of it's bare nature? Now we've got to look up neat ways to
combine and grep for :?[]{} etc.) Also, now you have coders on the
same project using their personal preference.

If something isn't broken, why fix it? That was the basis on my
original comment about things that actually were underway or brought
up due to issues.

Before I get off my sandbox, and go back to the shadows on the dev
list, someone privately replied to me and said this will help because
it will "its hurting lots of people's eyes (and wrists on the long
term)" - I'm taking that as a joke.

I understand I can use the "long syntax" still. Great. But *why*
introduce a second one? I can't even read half the Perl I see nowadays
because people have shortcutted so much crap. As I've said PHP is my
bread and butter, please don't make life harder by making syntax
changes that enable developers to be more cryptic code. I'm a
minimalist myself, I like smaller chunks of clean code, but this idea
is *unnecessary* as nothing is broken. I can only imagine the poor PHP
developers bastardizing this so badly it takes hours to decypher what
they are trying to do.

I have a feeling this is getting adopted either way, but I feel
obligated as a user to ask "wtf?"

- mike