Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37974
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.142.187 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
        b=LqrJ5DTsip9qL4/20gqaT4auVCu705joN0n4RldYifpvsaswLYzhC0qATJx5NAv78GXWXebrrm2zQkDyH/8t4t60XbYgeLIdpowUoD83/YRuET0m8UQX9g/nvIzSZj2vTHxx7skm3TPcoJbgKU1bjmfMShAG1te5ePrNk7n8QUQ=
Message-ID: <e2e02fe0805281054m4da38dbbt1e1ab02704238955@mail.gmail.com>
Date: Wed, 28 May 2008 10:54:56 -0700
To: jani.taskinen@iki.fi
Cc: Mike <ipso@snappymail.ca>, "Mailing List" <internals@lists.php.net>
In-Reply-To: <483D95A5.1040206@sci.fi>
MIME-Version: 1.0
Content-Type: multipart/alternative; 
	boundary="----=_Part_4800_7560202.1211997296802"
References: <0412F6FE505049F7901EAB8C61774839@pc>
	 <87.77.15519.9E47C384@pb1.pair.com>
	 <97.F8.15519.1229C384@pb1.pair.com> <483C94EA.90507@zend.com>
	 <483C95DD.6000006@sci.fi>
	 <alpine.DEB.0.98.0805280828340.32607@kossu.ez.no>
	 <698DE66518E7CA45812BD18E807866CE01A53A06@us-ex1.zend.net>
	 <e2e02fe0805280856r553fe343la015cf82e12d4b07@mail.gmail.com>
	 <1211994665.7621.39.camel@ipso.snappymail.ca>
	 <483D95A5.1040206@sci.fi>
Subject: Re: [PHP-DEV] Re: Short syntax for array literals [...]
From: chrisstocktonaz@gmail.com ("Chris Stockton")

------=_Part_4800_7560202.1211997296802
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello,

On Wed, May 28, 2008 at 10:25 AM, Jani Taskinen <jani.taskinen@sci.fi>
wrote:

> Exactly. Open this can of worms and soon PHP is something else than easy to
> learn.. someone already mentioned that {} thing for objects.. :)
>
> Sidenote: There are more important things to solve in PHP 5.3 (and
> especially HEAD) than adding this little syntax sugar..
>
> --Jani
>
It's not syntax sugar, it's a construct which is used across many other
languages. It will improve the language for other people and might help
people to learn PHP. If we have resource issues commiting one line of
grammar the project has other issues to deal with.


>
>
> Mike wrote:
>
>> In my opinion I don't think PHP would be where it is today if it wasn't
>> for being so easy to learn and use.
>
>
>> I attribute this directly to the fact that it didn't use a lot of
>> "syntax sugar" that is unreadable and can't be "Googled" for. You can't
>> Google "[]", and my guess is searching PHP.net for "[]" won't return
>> anything useful either.
>> Using Array() is SELF EXPLANATORY! Anyone can see that, search Google
>> for "Array" and learn something about it.
>> How many man hours are going to be wasted:
>> 1. Searching for what the heck [] actually is.
>
>
Anyone who has gotten to a level of knowing how to assign php variables will
likely have any troubles understanding what:
$config = ['smtpHost' => 'example.org'];
$oSmtp = someSmtpTransport($config['smtpHost']);

Is doing, and if you have a super complex multi-dimensional array,
regardless of brackets or array syntax it will be hard to understand by a
php new comer.


>> 2. Explaining to people that [] is the same as Array.
>
> $foo = Array('foo' => 'bar');
var_dump($foo);
$foo = ['foo' => 'bar'];
var_dump($foo);

Explained.


>> 3. Changing coding standards for projects to prevent [] from being
>> used.
>
> 4. Enforcing coding standards for projects to prevent [] from being
>> used.
>
> $str = "$var {$foo} " . $bar . " $see " . ' tconst ' . $not . ' $parsed ';

We already face issues with more then one way to do things, we deal with it
and it has not proven to be to difficult.


>
>> 5. Trying to change [] back to Array in hopes of getting code to work on
>> older versions of PHP.
>
> If your projects target versions are older versions then create backwards
compatible code just like you do with PHP4 classes and PHP5 classes.


>
>> 6. All the man hours wasted on it ALREADY that I'm sure could be much
>> better spent getting PHP 5.3/6.0 out.
>
> The discussion is the wasted time, not the code or implementation.


>
>>
>> There are enough roadblocks and other things to worry about already, why
>> would we want to add MORE? Especially for something with so little to
>> gain (if anything at all).
>
> Gain to whom? Remember, their is an entire community of developers out
their besides the people on this list who are accustomed to such use for
arrays. Also, a community of developers who would like an alternative syntax
to array to clean up their code a little, like me.


>
>>
>> This isn't about "well if you don't like it, don't use it" either,
>> because no matter what it will be forced on people who don't like it
>> eventually. People who like it will be constantly changing Array() -> []
>> and people who hate it will be constantly changing [] -> Array(). More
>> wasted time.
>
> Just like string literals $str = 'foo'; and $str = "foo";
class Foo {
    public $bar;
    public $baz;
    public $qux;

VS

class Foo {
    public $bar, $baz, $qux;

$obj = new Stdclass;
$obj = (object) NULL;

Really guys my only point is that we should not disregard a proposal for the
sake of having more then one way to do something. That is the beauty of PHP
and any successful language, it appeals to a wide variety of coding
standards, methodologies and paradigms. If you just think about it you can
name tons of things in PHP that let you do the same thing with two syntax's.
This is part of php's success. Some things are easier for people to learn
then they are for others.

-Chris

------=_Part_4800_7560202.1211997296802--