Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:27805
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain leedsmet.ac.uk designates 160.9.128.17 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 5 Feb 2007 12:35:32 -0000
Message-ID: <CDA511FF6152D14E922434CE338CE8BB04210152@leedsmet-exch1.leedsmet.ac.uk>
Thread-Topic: [PHP-DEV] Syntactic improvement to array
thread-index: AcdIplOPd+RTaBD1QiSquGExFqonDgAc4TxA
To: <internals@lists.php.net>
Subject: RE: [PHP-DEV] Syntactic improvement to array
From: M.Ford@leedsmet.ac.uk ("Ford, Mike")

On 04 February 2007 21:41, Zeev Suraski wrote:

> At 23:27 04-02-07, Pierre wrote:
> > On 2/4/07, Zeev Suraski <zeev@zend.com> wrote:
> > > At 20:14 04-02-07, Pierre wrote:
> > > > Hi,
> > > >=20
> > > > On 2/4/07, Ilia Alshanetsky <ilia@prohost.org> wrote:
> > > > > I personally find array extremely clear, in recent weeks I
> > > > > had to do A LOT of JavaScript work where the array syntax
> > > > > works in a manner you suggest for PHP and its a massive pain.
> > > > > It does not make for a very clear code. I think the syntax
> > > > > you propose is extremely confusing and we should stick to
> > > > > what we have right now.=20
> > > >=20
> > > > If someone does not like this new syntax, he can stick to
> > > > array(). It is in no way an argument to refuse the new syntax
> > > > addition.=20
> > >=20
> > > We never believed in that approach and we're not about to start
> > > now :).=20
> >=20
> > What I mean is that the new syntax does not any drawback besides
> > hurting a couple of people eyes (I'm pretty sure that most of our
> > users will like it). The changes have no effect on how your scripts
> > will run, not like the numerous changes we applied in 5.x until now.
>=20
> One of the key guidelines of the language definition process of PHP
> was that we don't want multiple ways of doing the same thing, and we
> don't buy the argument of 'why do you care?  you can still do it the
> other way'.  Only if the new way is significantly better than the old
> way of doing things (i.e. much faster / much simpler, etc.) we
> consider it.  I think it's been a very good guideline and helped us a
> lot in keeping PHP relatively clean for a very long time.

I hadn't come across this as a stated PHP principle, and I actually
don't buy it either in respect of PHP[*] or in general.  It's often the
case, as is becoming clear with this, that different people have widely
divergent views about what is clear and easy to use/read and what isn't,
and providing alternatives that suit both camps is to me a very positive
move -- you'd end up pleasing far more people far more of the time than
by sticking rigidly to the original option.

[*] I enter into evidence here the alternative ":" block structure,
which dates back further than I care to delve (but am extremely glad
of); many function (or language construct) aliases, such as print/echo,
exit/die; foreach in place of reset()/each(); 3 different ways (soon to
be 4) to write a string literal; and even the inclusion of string
slicing using (ironically) a [:] syntax on the PHP 6 feature list.

> The new array syntax is arguably clearer (although some here
> disagree).  It's not MUCH clearer to the sense that it's a no
> brainer, which makes things more complicated.

In your opinion.  Personally, I find the [] syntax so much clearer that
I would rate it a no-brainer to include it.  But, by the same token,
there are also people on here who would rate it a no-brainer *not* to
include it.

Finally, I really don't see the argument that the [] syntax is non-
obvious. If you're working with arrays at all, you have to know that
[] is used to subscript out individual elements, so it seems to me
abundantly clear that other uses of [] are most likely to be array-
related and a quick step to the Arrays section of the manual would be
in order.

OK, as a mere enthusiastic user I've probably said more than I am
entitled to, so I'll disappear for now...!!

Cheers!

Mike

---------------------------------------------------------------------
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Headingley Campus, LEEDS,  LS6 3QS,  United Kingdom
Email: m.ford@leedsmet.ac.uk
Tel: +44 113 283 2600 extn 4730      Fax:  +44 113 283 3211=20


To view the terms under which this email is distributed, please go to http:=
//disclaimer.leedsmet.ac.uk/email.htm