Proposal: Array syntax

Ken Tossell

22 years ago

Christian Schneider wrote:

> Note: I checked the newsgroup archive but couldn't find a discussion
> about this. After not hearing back about my proposed enhancement to
> debug_backtrace() and the dangling comma for function call parameters
> being rejected I wonder if I'm using the right mailing list for this :-)

You're on the right list. If you don't get any more responses, it's just
because something's wrong with your idea. ;-)

Looks cool, though I've never touched ZE2 and, sadly, have no knowledge
of the parser...

Ken

Rasmus Lerdorf

22 years ago

More magic.  The difference between these two lines:

$a = array(1,2,3);
$a = [ 1,2,3 ];

is that with the first you can go and look up the array keyword and see
what it does, whereas on the second line you have no idea.  You can't look
up a [

You are right that arrays are common and that this might be a case to
break the no-magic PHP rule, but I am personally not in favour of breaking
it for this case.

-Rasmus

On Wed, 5 Nov 2003, Christian Schneider wrote:

Andi Gutmans

22 years ago

Hi Christian,

Personally I don't like having two ways of doing things. It makes it harder
for people to read scripts.
However, I think the proposed syntax is significantly more elegant than
today's array() which makes me think twice about the idea and possibly
making an exception to the rule. I think it'll improve the look of PHP
scripts. Also I think people calling methods using call_user_method([$obj,
"method"]); will find it sexier than the array() syntax.
I guess I think it'd be interesting to see what other's think. Also,
another point to check is if list() can also be converted into [] because
having a hybrid wouldn't be too nice.

Andi

At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:

Christian Schneider

22 years ago

Andi Gutmans wrote:

> I guess I think it'd be interesting to see what other's think. Also,
> another point to check is if list() can also be converted into []
> because having a hybrid wouldn't be too nice.

Having list() work the same way would be very sexy indeed:
[$a, $b] = [$b, $a];

To be honest I never really liked the distinction between list() and
array().

Using [] for arrays is also consistent with dereferenceing arrays and
therefore shouldn't confuse people really.

My first shot at extending the parser to allow [] for list() failed
though as both T_LIST and T_ARRAY are used in expr_without_variable. But
I'm sure you could find a clever way around this, my knowledge of yacc
is still limited :-)

But even without [] for list() I think [] for array() would be nice ;-)

- Chris

s0niX

22 years ago

Hi

The problem i see when using array() (or list()) is that it nearly looks
like it is a function, but it isn't. Using [] instead would clearly
mark this difference.
array() and list() are special language constructs, why shouldn't they look a bit special?
This doesn't break backwards compatibility and it makes new code look
better and more readable.

Daniel Penning

Am Mittwoch, 5. November 2003 um 09:49 schrieben Sie:

AG> Hi Christian,

AG> Personally I don't like having two ways of doing things. It makes it harder
AG> for people to read scripts.
AG> However, I think the proposed syntax is significantly more elegant than
AG> today's array() which makes me think twice about the idea and possibly
AG> making an exception to the rule. I think it'll improve the look of PHP
AG> scripts. Also I think people calling methods using call_user_method([$obj,
AG> "method"]); will find it sexier than the array() syntax.
AG> I guess I think it'd be interesting to see what other's think. Also,
AG> another point to check is if list() can also be converted into [] because
AG> having a hybrid wouldn't be too nice.

AG> Andi

AG> At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:

Mike Robinson

22 years ago

s0niX wrote:

> The problem i see when using array() (or list()) is that it nearly looks
> like it is a function, but it isn't. Using [] instead would clearly
> mark this difference.
> array() and list() are special language constructs, why shouldn't
> they look a bit special?
> This doesn't break backwards compatibility and it makes new code look
> better and more readable.
>

Indeed. It's a nice idea.
Having that syntax as an alternative to list() would be cool too.

Whether it has enough steam to get around the magic rule I'll
leave to others, because the rule is there for a reason. :)

Best Regards
Mike Robinson

Dirkjan Ochtman

22 years ago

I like it a lot as well. Having the [] syntax also support range()-like
calls would be a very nice idea as well. :D

Regards,

Manuzhai

"Mike Robinson" <mike@fiddy8.com> wrote in message
news:PPEJIJHNCLOJJONNJNMJCEKPCAAA.mike@fiddy8.com...

> s0niX wrote:
>
> > The problem i see when using array() (or list()) is that it nearly looks
> > like it is a function, but it isn't. Using [] instead would clearly
> > mark this difference.
> > array() and list() are special language constructs, why shouldn't
> > they look a bit special?
> > This doesn't break backwards compatibility and it makes new code look
> > better and more readable.
> >
>
> Indeed. It's a nice idea.
> Having that syntax as an alternative to list() would be cool too.
>
> Whether it has enough steam to get around the magic rule I'll
> leave to others, because the rule is there for a reason. :)
>
> Best Regards
> Mike Robinson
>
>
> >
> > Am Mittwoch, 5. November 2003 um 09:49 schrieben Sie:
> >
> > AG> Hi Christian,
> >
> > AG> Personally I don't like having two ways of doing things. It
> > makes it harder
> > AG> for people to read scripts.
> > AG> However, I think the proposed syntax is significantly more
> > elegant than
> > AG> today's array() which makes me think twice about the idea and
> > possibly
> > AG> making an exception to the rule. I think it'll improve the
> > look of PHP
> > AG> scripts. Also I think people calling methods using
> > call_user_method([$obj,
> > AG> "method"]); will find it sexier than the array() syntax.
> > AG> I guess I think it'd be interesting to see what other's think. Also,
> > AG> another point to check is if list() can also be converted
> > into [] because
> > AG> having a hybrid wouldn't be too nice.
> >
> > AG> Andi
> >
> > AG> At 12:33 AM 11/5/2003 +0100, Christian Schneider wrote:
> > >>I propose to add an alternative (backward compatible) short
> > array creation
> > >>syntax:
> > >>$a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
> > >>
> > >>It can also be used in function calls:
> > >>img(['src' => "logo.gif", 'alt' => "Logo"]);
> > >>
> > >>Reason behind this change: Arrays are used a lot and should
> > therefore have
> > >>as little syntactic overhead as possible. And I think the short
> > syntax is
> > >>also easier to read and write.
> > >>
> > >>A patch for the parser is trivial and is attached for Zend2.
> > >>
> > >>Note: I checked the newsgroup archive but couldn't find a
> > discussion about
> > >>this. After not hearing back about my proposed enhancement to
> > >>debug_backtrace() and the dangling comma for function call parameters
> > >>being rejected I wonder if I'm using the right mailing list for this

:-)

Cesare D'Amico

22 years ago

On Wednesday 05 November 2003 09:49, Andi Gutmans wrote:

> However, I think the proposed syntax is significantly more elegant than
> today's array() which makes me think twice about the idea and possibly
> making an exception to the rule. I think it'll improve the look of PHP
> scripts. Also I think people calling methods using call_user_method([$obj,
> "method"]); will find it sexier than the array() syntax.

This syntax is really pythonian... I can see python programmers prouding
themselves as "trend makers" in programming languages ;)

Ciao
ce

--
"L'Informatica riguarda i computer tanto quanto l'astronomia riguarda i
telescopi"
-- E. W. Dijkstra

Alexey Trunyov

22 years ago

Andi Gutmans wrote:

> Personally I don't like having two ways of doing things. It makes it
> harder for people to read scripts.

It looks like the one way of doing two separate things.
I mean that semanics of two usages of square brackets as operator is
inverse depending on whether it is used in unary or binary form.

Being unary, square brackets operator is array constructor.
And being applied to left-side variable it becomes a reference to an
array element.

These two usages do some sort of inverse stuff.

BTW is [1][0]==1 true with the proposed syntax?

> However, I think the proposed syntax is significantly more elegant than
> today's array() which makes me think twice about the idea and possibly
> making an exception to the rule. I think it'll improve the look of PHP
> scripts. Also I think people calling methods using
> call_user_method([$obj, "method"]); will find it sexier than the array()
> syntax.
> I guess I think it'd be interesting to see what other's think. Also,
> another point to check is if list() can also be converted into []
> because having a hybrid wouldn't be too nice.

That was what I think although I am not the one to listened to.

Antony Dovgal

22 years ago

On Wed, 05 Nov 2003 19:34:52 +0700
Alexey Trunyov <al@forest.akadem.ru> wrote:

> Andi Gutmans wrote:
>
> > Personally I don't like having two ways of doing things. It makes it
> > harder for people to read scripts.
>
> It looks like the one way of doing two separate things.

No, it looks like someone trying to turn PHP into Perl (or Python).
Personally I would prefer not to import Perl-style & Python-style syntax to PHP.
These things already work well(yes, you can think, that array() & range() are ugly, but they are already used in tonns of projects) and I can't see any reasons to change such fundamental things just because version number changes from 4 to 5.
If you really like this syntax - use Perl or Python, or whatever you want, but I really can't understand why PHP should allow you to use this syntax too.

---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net

Christian Schneider

22 years ago

Ok, I tried to just listen to what people are saying but this comment
went too far ;-)

Antony Dovgal wrote:

> No, it looks like someone trying to turn PHP into Perl (or Python).

I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
have some idea about where the syntax could be improved IMHO.

> Personally I would prefer not to import Perl-style & Python-style syntax to PHP.

PHP is a mix of C, Perl and other styles anyway, why deny it? It's
strength is that it's a pragmatic and simple language but that doesn't
mean that nothing should be changed ever.

> These things already work well(yes, you can think, that array() & range()
> are ugly, but they are already used in tonns of projects) and I can't see

I don't want to break existing programs. And I don't care about range()
(or even list() too much for that matter), I just recognize the fact the
I'm using a lot of array() and it is both unnecessarily hard to write
_and_ read.
Saying that array() works well and [] is incomprehensible just does not
match my experience. Both for myself (some years of programming
experience) and for newbies. I saw no difference teaching people to
initialize an array with array() or []. Someone new to programming has
to memorize that he has to write $a = array() (and not $a = new array()
for example) anyway, $a = [] would be just as easy IMHO.

> any reasons to change such fundamental things just because version number
> changes from 4 to 5.

So why was the whole private/public/static/throw/catch thing introduced?
Following your logic people who want this should use Java. I'm much
more worried about code getting unreadable because of these extensions
actually. It turned PHP into a much more complex language but since it
is all optional I don't mind. But to deny some simple (and backward
compatible) syntactic sugar to people who just want an easy to use
language seems missing the point to me.

> If you really like this syntax - use Perl or Python, or whatever you want,
> but I really can't understand why PHP should allow you to use this

syntax too.

I like some of the Python syntax. But some of it is cumbersome. Same
with PHP. But I think PHP is closer to what I want so what's wrong with
trying to improve it where it's possible (and easily done)? I used Perl
4 back in the early days but I was horrified by some stuff they added
with Perl 5. Perl 6 is actually making some things better again (but no,
I'm not going to use it when it comes out in 2010).

[ 'my_cents' => .02 ],
- Chris

Nicolas Toper

22 years ago

Hi,

I'm new to the list. I've come trough your post and as a PHP "end user" I
can say that array are easy to use but they could be a lot easier...

You don't want Perl features? Please don't delete the for each operator :=)

-----Message d'origine-----
De : Christian Schneider [mailto:cschneid@cschneid.com]
Envoye : mercredi 5 novembre 2003 16:35
A : Antony Dovgal
Cc : internals@lists.php.net
Objet : Re: [PHP-DEV] Proposal: Array syntax


Ok, I tried to just listen to what people are saying but this comment
went too far ;-)

Antony Dovgal wrote:

> No, it looks like someone trying to turn PHP into Perl (or Python).

I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
have some idea about where the syntax could be improved IMHO.

> Personally I would prefer not to import Perl-style & Python-style syntax

to PHP.

PHP is a mix of C, Perl and other styles anyway, why deny it? It's
strength is that it's a pragmatic and simple language but that doesn't
mean that nothing should be changed ever.

> These things already work well(yes, you can think, that array() & range()
> are ugly, but they are already used in tonns of projects) and I can't see

I don't want to break existing programs. And I don't care about range()
(or even list() too much for that matter), I just recognize the fact the
I'm using a lot of array() and it is both unnecessarily hard to write
_and_ read.
Saying that array() works well and [] is incomprehensible just does not
match my experience. Both for myself (some years of programming
experience) and for newbies. I saw no difference teaching people to
initialize an array with array() or []. Someone new to programming has
to memorize that he has to write $a = array() (and not $a = new array()
for example) anyway, $a = [] would be just as easy IMHO.

> any reasons to change such fundamental things just because version number
> changes from 4 to 5.

So why was the whole private/public/static/throw/catch thing introduced?
Following your logic people who want this should use Java. I'm much
more worried about code getting unreadable because of these extensions
actually. It turned PHP into a much more complex language but since it
is all optional I don't mind. But to deny some simple (and backward
compatible) syntactic sugar to people who just want an easy to use
language seems missing the point to me.

> If you really like this syntax - use Perl or Python, or whatever you want,
> but I really can't understand why PHP should allow you to use this

syntax too.

I like some of the Python syntax. But some of it is cumbersome. Same
with PHP. But I think PHP is closer to what I want so what's wrong with
trying to improve it where it's possible (and easily done)? I used Perl
4 back in the early days but I was horrified by some stuff they added
with Perl 5. Perl 6 is actually making some things better again (but no,
I'm not going to use it when it comes out in 2010).

[ 'my_cents' => .02 ],
- Chris

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Ilia A.

22 years ago

On November 5, 2003 10:34 am, Christian Schneider wrote:

> PHP is a mix of C, Perl and other styles anyway, why deny it? It's
> strength is that it's a pragmatic and simple language but that doesn't
> mean that nothing should be changed ever.

PHP strength (IMHO) is it's simple and clear syntax, which allows people who
come from background in other programming languages can quickly recognize and
get used to. Creating confusing alternate syntaxes will bring us ever closer
to Perl 6 where there are dozens of way to do the same thing. The end results
in a confusing and hard to read/write language that all but the most
dedicated of users refuse to use.

> I don't want to break existing programs. And I don't care about range()
> (or even list() too much for that matter), I just recognize the fact the
> I'm using a lot of array() and it is both unnecessarily hard to write
> _and_ read.

That's bull, 5 characters is hard to write? If anything those 5 characters
make it absolutely clear to ANYONE that the data is an array and not an
object or a string or some other type. When I first saw the syntax is took me
a few seconds to realize what it does and the problem would only be
compounded when the code is found within an pre-existing complex script.

Ilia

Rasmus Lerdorf

22 years ago

On Wed, 5 Nov 2003, Ilia Alshanetsky wrote:

> On November 5, 2003 10:34 am, Christian Schneider wrote:
> > PHP is a mix of C, Perl and other styles anyway, why deny it? It's
> > strength is that it's a pragmatic and simple language but that doesn't
> > mean that nothing should be changed ever.
>
> PHP strength (IMHO) is it's simple and clear syntax, which allows people who
> come from background in other programming languages can quickly recognize and
> get used to. Creating confusing alternate syntaxes will bring us ever closer
> to Perl 6 where there are dozens of way to do the same thing. The end results
> in a confusing and hard to read/write language that all but the most
> dedicated of users refuse to use.

Well, like I said before, I am not sure this is a clear case of that.  I'm
probably the biggest defender around of the no-magic rule, but [] does
imply something array-related to most people, so I think the magic part is
much smaller than in other proposals we have seen.

> That's bull, 5 characters is hard to write? If anything those 5 characters
> make it absolutely clear to ANYONE that the data is an array and not an
> object or a string or some other type. When I first saw the syntax is took me
> a few seconds to realize what it does and the problem would only be
> compounded when the code is found within an pre-existing complex script.

I do agree that [1,2,3] is not easier to read than array(1,2,3), but I
don't think there is a huge difference between the two.  I guess we could
sample a few newbie users to see what they think $a = [1,2,3]; would do.
Of course, then people are going to try to do $a = $b[1,2,3]; and then we
are all messed up.

-Rasmus

Ilia A.

22 years ago

On November 5, 2003 11:21 am, you wrote:

> Well, like I said before, I am not sure this is a clear case of that.  I'm
> probably the biggest defender around of the no-magic rule, but [] does
> imply something array-related to most people, so I think the magic part is
> much smaller than in other proposals we have seen.

Right now [] could either be an array element or an offset. Now it can either
be an array element or a string offset or an attempt to create a new array.
Individually it may be fine, but I am certain we'll end up with bug reports
of people trying to do $a = $b[1,2,3]; (copied from your resonse ;) ) and
similar. Of course someone would then want to do $a[1,2,3] = [3,4,5]; and
we're happily on our road to obfuscation.

I mean c'mon, is 5 characters that much of a problem and is absolute code
clarity not worth those 5 characters? Character efficiency is done in Perl,
where you can do things like ~= and @_, but that makes Perl code naturally
obfuscated and I do not think that's a good way to go.

Ilia

Andi Gutmans

22 years ago

At 11:48 AM 11/5/2003 -0500, Ilia Alshanetsky wrote:

>On November 5, 2003 11:21 am, you wrote:
> > Well, like I said before, I am not sure this is a clear case of that.  I'm
> > probably the biggest defender around of the no-magic rule, but [] does
> > imply something array-related to most people, so I think the magic part is
> > much smaller than in other proposals we have seen.
>
>Right now [] could either be an array element or an offset. Now it can either
>be an array element or a string offset or an attempt to create a new array.
>Individually it may be fine, but I am certain we'll end up with bug reports
>of people trying to do $a = $b[1,2,3]; (copied from your resonse ;) ) and
>similar. Of course someone would then want to do $a[1,2,3] = [3,4,5]; and
>we're happily on our road to obfuscation.
>
>I mean c'mon, is 5 characters that much of a problem and is absolute code
>clarity not worth those 5 characters? Character efficiency is done in Perl,
>where you can do things like ~= and @_, but that makes Perl code naturally
>obfuscated and I do not think that's a good way to go.

I don't believe in saving characters. You probably know that I tend to
prefer looooooong meaningful names and not have all sorts of magic. I think
in this case, it's not a matter of saving the typing as it looks much
better and IMO is more intuitive.
Anyway, it's no biggy and if most people here think it shouldn't be added
then that's fine with me.

Andi

Christian Schneider

22 years ago

Andi Gutmans wrote:

> I don't believe in saving characters.

Agreed, it's not about saving characters (only).

> Anyway, it's no biggy and if most people here think it shouldn't be
> added then that's fine with me.

Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
couldn't figure out if they are pro or con (-:C

- Chris

Jani Taskinen

22 years ago

On Wed, 5 Nov 2003, Christian Schneider wrote:

>Andi Gutmans wrote:
> > I don't believe in saving characters.
>
>Agreed, it's not about saving characters (only).
>
>> Anyway, it's no biggy and if most people here think it shouldn't be
>> added then that's fine with me.
>
>Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
>couldn't figure out if they are pro or con (-:C

I think Andi meant the PHP developers, not some random user out there..
(Last time I checked, OS isn't synonym for democrazy. :)

--Jani

Derick Rethans

22 years ago

On Wed, 5 Nov 2003, Christian Schneider wrote:

> Andi Gutmans wrote:
>  > I don't believe in saving characters.
>
> Agreed, it's not about saving characters (only).
>
> > Anyway, it's no biggy and if most people here think it shouldn't be
> > added then that's fine with me.
>
> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
> couldn't figure out if they are pro or con (-:C

Do you think your vote counts? :)

Derick

--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------

Rasmus Lerdorf

22 years ago

On Wed, 5 Nov 2003, Christian Schneider wrote:

> Andi Gutmans wrote:
>  > I don't believe in saving characters.
>
> Agreed, it's not about saving characters (only).
>
> > Anyway, it's no biggy and if most people here think it shouldn't be
> > added then that's fine with me.
>
> Ok, a quick head count gave 9 people pro, 6 people con and 3 people I
> couldn't figure out if they are pro or con (-:C

In case it wasn't clear, I am a -0 on this.  I don't mind the syntax, but
having two different syntaxes is the big problem here.

-Rasmus

Edin Kadribasic

22 years ago

On Wednesday, Nov 5, 2003, at 17:48 Europe/Copenhagen, Andi Gutmans
wrote:

> Anyway, it's no biggy and if most people here think it shouldn't be
> added then that's fine with me.

I like the new syntax proposal, especially when passing arrays as
function parameters.

+1 here.

Edin

Shane Caraveo

22 years ago

+1 for the [] syntax.  I also feel it's much more intuitive.  Calling
(what looks like) a function to make an array seems plain silly to me.

Shane

Wez Furlong

22 years ago

> Anyway, it's no biggy and if most people here think it shouldn't be added
> then that's fine with me.

Thies reminded me of something that should be considered here; we talked
about
and alternative array syntax for overloaded objects where all the array
indices are
required in one "chunk" to be able to resolve an overloaded array lookup.

eg: in COM, if you have a 2-Dimensional SafeArray, and you want to lookup an
element, you need to provide both dimension offsets at the same time.

$foo = $arr[0][1];

This cannot be acheived with the current breadcumb evaluation used by the
engine, as the engine will try to resolve $tmp = $arr[0]; $foo = $tmp[1];

One of the possible solutions was the pascal style array indexing:

$foo = $arr[0,1];

If we overload [] too much, we really will end up with unmaintainable code.

I'm -1 on the alternative array declaration syntax unless we implement the
pascal syntax (or something else useful!) for ZE2 OO handlers, in which
case I'm -0.

--Wez.

Stig S. Bakken

22 years ago

On Wed, 2003-11-05 at 17:48, Andi Gutmans wrote:

> At 11:48 AM 11/5/2003 -0500, Ilia Alshanetsky wrote:
> >On November 5, 2003 11:21 am, you wrote:
> > > Well, like I said before, I am not sure this is a clear case of that.  I'm
> > > probably the biggest defender around of the no-magic rule, but [] does
> > > imply something array-related to most people, so I think the magic part is
> > > much smaller than in other proposals we have seen.
> >
> >Right now [] could either be an array element or an offset. Now it can either
> >be an array element or a string offset or an attempt to create a new array.
> >Individually it may be fine, but I am certain we'll end up with bug reports
> >of people trying to do $a = $b[1,2,3]; (copied from your resonse ;) ) and
> >similar. Of course someone would then want to do $a[1,2,3] = [3,4,5]; and
> >we're happily on our road to obfuscation.
> >
> >I mean c'mon, is 5 characters that much of a problem and is absolute code
> >clarity not worth those 5 characters? Character efficiency is done in Perl,
> >where you can do things like ~= and @_, but that makes Perl code naturally
> >obfuscated and I do not think that's a good way to go.
>
> I don't believe in saving characters. You probably know that I tend to
> prefer looooooong meaningful names and not have all sorts of magic. I think
> in this case, it's not a matter of saving the typing as it looks much
> better and IMO is more intuitive.
> Anyway, it's no biggy and if most people here think it shouldn't be added
> then that's fine with me.

I don't see a reason for introducing [] for arrays.  And this is coming
from the guy who came up with the original ({ }) syntax in
3.0-pre-alpha, which was replaced with array() for readability.

Let's sum up the pros and cons:

Pros: sexiness?

Cons: another BC issue, syntax obfuscation, potential grammar conflicts

I used to not like array() because it was too verbose, but today I think
it's great because its meaning is very crisp and clear when you read the
code.  Screwing up readable syntax in favor of sexiness is Perl's
business, not PHP's.

- Stig

Andi Gutmans

22 years ago

At 09:58 AM 11/6/2003 +0100, Stig S. Bakken wrote:

>Let's sum up the pros and cons:
>
>Pros: sexiness?
>
>Cons: another BC issue, syntax obfuscation, potential grammar conflicts

Just to be more accurate there are no BC issues and as far as I know, there
aren't any grammar conflicts.

Andi

Stig S. Bakken

22 years ago

On Thu, 2003-11-06 at 13:04, Andi Gutmans wrote:

> At 09:58 AM 11/6/2003 +0100, Stig S. Bakken wrote:
> >Let's sum up the pros and cons:
> >
> >Pros: sexiness?
> >
> >Cons: another BC issue, syntax obfuscation, potential grammar conflicts
>
> Just to be more accurate there are no BC issues and as far as I know, there
> aren't any grammar conflicts.

With BC issues I mean that there will be one more hurdle preventing code
originally written with PHP 5 to run on PHP 4.

- Stig

Marco Tabini

22 years ago

Rasmus Lerdorf wrote:

> On Wed, 5 Nov 2003, Ilia Alshanetsky wrote:
>
>>On November 5, 2003 10:34 am, Christian Schneider wrote:
>>
>>>PHP is a mix of C, Perl and other styles anyway, why deny it? It's
>>>strength is that it's a pragmatic and simple language but that doesn't
>>>mean that nothing should be changed ever.
>>
>>PHP strength (IMHO) is it's simple and clear syntax, which allows people who
>>come from background in other programming languages can quickly recognize and
>>get used to. Creating confusing alternate syntaxes will bring us ever closer
>>to Perl 6 where there are dozens of way to do the same thing. The end results
>>in a confusing and hard to read/write language that all but the most
>>dedicated of users refuse to use.
>
>
> Well, like I said before, I am not sure this is a clear case of that.  I'm
> probably the biggest defender around of the no-magic rule, but [] does
> imply something array-related to most people, so I think the magic part is
> much smaller than in other proposals we have seen.
>

But isn't there a big difference between an assignment and a reference?
I, for one, think that language constructs should be as univocal as
possible in order to minimize confusion, lest we end up having to read
something like:

$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];

I don't know about you, but I can't even begin to count the brackets in
there... :-)

Cheers,


Marco

George Schlossnagle

22 years ago

On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:

> But isn't there a big difference between an assignment and a reference?
> I, for one, think that language constructs should be as univocal as
> possible in order to minimize confusion, lest we end up having to read
> something like:
>
> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>
> I don't know about you, but I can't even begin to count the brackets
> in there... :-)

is that any less clear than

$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
array(array(1,2,3,4), 4, array(1,2)));

Both examples can be made crystal clear with appropriate whitespace.

George

Marco Tabini

22 years ago

George Schlossnagle wrote:

>
> On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>
>> But isn't there a big difference between an assignment and a reference?
>> I, for one, think that language constructs should be as univocal as
>> possible in order to minimize confusion, lest we end up having to read
>> something like:
>>
>> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>
>> I don't know about you, but I can't even begin to count the brackets
>> in there... :-)
>
>
> is that any less clear than
>
> $a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
> array(array(1,2,3,4), 4, array(1,2)));
>
> Both examples can be made crystal clear with appropriate whitespace.

Except that the word array provides a nice break *and* it does not
create confusion in the use of a language construct (see my previous msgs).

Cheers,

Marco

Christian Schneider

22 years ago

Marco Tabini wrote:

> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];

$a = array(array(1,2,3),array(1=>array(1,3,2,2),
"a"=>array(array(1,2,3,4),4,array(1,2)));

What was your point again? ;-)

- Chris

Marco Tabini

22 years ago

Christian Schneider wrote:

> Marco Tabini wrote:
>
>> $a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>
>
> $a = array(array(1,2,3),array(1=>array(1,3,2,2),
> "a"=>array(array(1,2,3,4),4,array(1,2)));
>

Besides my previous points, something even more abominable:

$a = [1,2,$b[11]];

Is that confusing enough for you? ;-)

Mt.

Andi Gutmans

22 years ago

At 11:58 AM 11/5/2003 -0500, George Schlossnagle wrote:

>On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>>But isn't there a big difference between an assignment and a reference?
>>I, for one, think that language constructs should be as univocal as
>>possible in order to minimize confusion, lest we end up having to read
>>something like:
>>
>>$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>
>>I don't know about you, but I can't even begin to count the brackets in
>>there... :-)
>
>is that any less clear than
>
>$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
>array(array(1,2,3,4), 4, array(1,2)));
>
>Both examples can be made crystal clear with appropriate whitespace.

I agree with that.

Andi

Jani Taskinen

22 years ago

On Wed, 5 Nov 2003, Andi Gutmans wrote:

>At 11:58 AM 11/5/2003 -0500, George Schlossnagle wrote:
>
>>On Nov 5, 2003, at 11:52 AM, Marco Tabini wrote:
>>>But isn't there a big difference between an assignment and a reference?
>>>I, for one, think that language constructs should be as univocal as
>>>possible in order to minimize confusion, lest we end up having to read
>>>something like:
>>>
>>>$a = [[1,2,3],[1=>[1,3,2,2], "a"=>[[1,2,3,4],4,[1,2]]];
>>>
>>>I don't know about you, but I can't even begin to count the brackets in
>>>there... :-)
>>
>>is that any less clear than
>>
>>$a = array(array(1,2,3), array(1 => array(1,3,2,2), array("a" =>
>>array(array(1,2,3,4), 4, array(1,2)));
>>
>>Both examples can be made crystal clear with appropriate whitespace.
>
>I agree with that.

So it's gonna be the pythonized version? ie. if there is no
appropriate whitespace -> parse error? :)

--Jani

Moriyoshi Koizumi

22 years ago

Rasmus Lerdorf <rasmus@lerdorf.com> wrote:

> I do agree that [1,2,3] is not easier to read than array(1,2,3), but I
> don't think there is a huge difference between the two.  I guess we could
> sample a few newbie users to see what they think $a = [1,2,3]; would do.
> Of course, then people are going to try to do $a = $b[1,2,3]; and then we
> are all messed up.

Yeah, it will mess us up all. I did a quick hack to realise this
feature. The patch is pasted below.

<?php
$a = array('ArrayArray' => 'nay');
var_dump($a[[0].[0]]);
?>

Indeed this works :) I'm not much interested in this kind of discussion
though.

Moriyoshi

Index: Zend/zend_language_parser.y
===================================================================
RCS file: /repository/Zend/Attic/zend_language_parser.y,v
retrieving revision 1.23
diff -u -r1.23 zend_language_parser.y
--- Zend/zend_language_parser.y 4 Aug 2002 06:39:44 -0000       1.23
+++ Zend/zend_language_parser.y 5 Nov 2003 17:42:40 -0000
@@ -484,6 +484,7 @@
|       '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr { zend_do_end
_silence(&$1 TSRMLS_CC); $$ = $3; }
|       scalar                          { $$ = $1; }
|       T_ARRAY '(' array_pair_list ')' { $$ = $3; }
+       |       '[' array_pair_list ']' { $$ = $2; }
|       '`' encaps_list '`'             { zend_do_shell_exec(&$$, &$2 TS
RMLS_CC); }
|       T_PRINT expr  { zend_do_print(&$$, &$2 TSRMLS_CC); }
;

Antony Dovgal

22 years ago

On Wed, 05 Nov 2003 16:34:52 +0100
Christian Schneider <cschneid@cschneid.com> wrote:

> I'm just trying to improve PHP. And I write _a lot_ of PHP code, so I
> have some idea about where the syntax could be improved IMHO.

changing the syntax is not the best way imho.

> PHP is a mix of C, Perl and other styles anyway, why deny it? It's
> strength is that it's a pragmatic and simple language but that doesn't
> mean that nothing should be changed ever.

because PHP is PHP.
in C you can use assembler code insertions, but it doesn't mean, that PHP's strength should be powered by allowing assembler insertions.
if in Python you can create new array, using $a = [];, it doesn't mean, that PHP should be able to do it in the same way.

> I don't want to break existing programs. And I don't care about range()
> (or even list() too much for that matter), I just recognize the fact the
> I'm using a lot of array() and it is both unnecessarily hard to write
> _and_ read.
> Saying that array() works well and [] is incomprehensible just does not
> match my experience. Both for myself (some years of programming
> experience) and for newbies. I saw no difference teaching people to
> initialize an array with array() or []. Someone new to programming has
> to memorize that he has to write $a = array() (and not $a = new array()
> for example) anyway, $a = [] would be just as easy IMHO.

this is very confusing way to improve PHP.
you will type 2 symbols instead of 7, but you forget, that you use almost same syntax for indexing arrays.
do you agree, that $a[] = ''; and $a = []; look almost similar for newbies?

>  > any reasons to change such fundamental things just because version number
>  > changes from 4 to 5.
>
> So why was the whole private/public/static/throw/catch thing introduced?
>   Following your logic people who want this should use Java. I'm much
> more worried about code getting unreadable because of these extensions
> actually. It turned PHP into a much more complex language but since it
> is all optional I don't mind. But to deny some simple (and backward
> compatible) syntactic sugar to people who just want an easy to use
> language seems missing the point to me.

you're misrepresenting my words.
PHP didn't have some kind of private/public/static/throw/catch before.
and you're trying to invent new kind of wheel, 'cause you think common model of wheel is "ugly".

> I like some of the Python syntax. But some of it is cumbersome. Same
> with PHP. But I think PHP is closer to what I want so what's wrong with
> trying to improve it where it's possible (and easily done)?

agree, and you can easily make PHP code not readable with such improvements.
again, I can't understand why PHP should have another way of creating new arrays.
there are so many things you can improve in PHP - why did you choose to change the syntax?

so, I'm still strongly against such improvements.

---
WBR,
Antony Dovgal aka tony2001
tony2001@phpclub.net

Christian Schneider

22 years ago

Antony Dovgal wrote:

> do you agree, that $a[] = ''; and $a = []; look almost similar for newbies?

And they both deal with arrays. That's not confusing to me.
Why have $a[] = ''; then in the first place? You already have
array_push($a, ''). Or do you seriously think $a[] = ''; shouldn't be there?

> PHP didn't have some kind of private/public/static/throw/catch before.

Not true, you could do the same thing manually. Very ugly but possible.
But that's academic.

> and you're trying to invent new kind of wheel, 'cause you think common model of wheel is "ugly".

I'm trying to remove bumps from existing wheels because I thinks the car
is almost perfect. That's the main problem: You think it needs whole new
constructs but the existing ones are perfect whereas I think some of the
existing constructs could use some polishing but have no need for 'big'
changes. And I accept that some people want things like throw, catch or
final but you don't accept that having an elegant syntax for writing
simple code is important to me.

> again, I can't understand why PHP should have another way of creating new arrays.

Again, cecause it's nicer to use (read and write) IMHO. Especially for
nested arrays and arrays in function calls.

> there are so many things you can improve in PHP - why did you choose to change the syntax?

Because I don't think PHP _needs_ major changes.
I was trying to convince people on the phpdev list that PHP4 should use
references instead of copying objects back then when it was designed but
was rejected. Now this is finally changed in PHP5 which is great. This
was basically my last major complaint about the object model and
language constructs and that's why I'm trying to work on the details.

- Chris

Michael Walter

22 years ago

>>I like some of the Python syntax. But some of it is cumbersome. Same
>>with PHP. But I think PHP is closer to what I want so what's wrong with
>>trying to improve it where it's possible (and easily done)?
>
>
> agree, and you can easily make PHP code not readable with such improvements.
> again, I can't understand why PHP should have another way of creating new arrays.
> there are so many things you can improve in PHP - why did you choose to change the syntax?

Cause array() really is used very often, and could be made much more
"pretty" (read: readable, expressive) with [].

Cheers,
Michael

PS: there was static without the keyword in ZE1.

Marco Tabini

22 years ago

Hi Andi, Christian--

From a logical standpoint, I think this could be very confusing. To me,
for one, square brackets imply reference, not assignment. Taking
something that means "take something out of the array" and now using it
to mean "put something in the array" makes the language a bit less
self-consistent... and, as Rasmus mentioned, less readable. Conciveness
is not everything--one also has to be able to understand his own code
after he's written it :-)

Cheers,


Marco

Andi Gutmans wrote:

Michael Walter

22 years ago

Very cool.

How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
no be the worth, just thinking out loud ;)

Christian Schneider wrote:

Michael Walter

22 years ago

> Very cool.
>
> How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
> no be the worth, just thinking out loud ;)

"might not be worth it"..

Kouber Saparev

22 years ago

Your idea is even cooler...;)

I would like to have these in PHP.

Kouber

"Michael Walter" <cm@leetspeak.org> wrote in message
news:3FA8BC03.9050104@leetspeak.org...

> Very cool.
>
> How about supporting .. syntax, btw. as in [1..3] or ["a".."z"]? Might
> no be the worth, just thinking out loud ;)
>
> Christian Schneider wrote:
> > I propose to add an alternative (backward compatible) short array
> > creation syntax:
> > $a = [ 1, 2, 3 ]; and $a = [ 'a' => 42, 'b' => "foo" ];
> >
> > It can also be used in function calls:
> > img(['src' => "logo.gif", 'alt' => "Logo"]);
> >
> > Reason behind this change: Arrays are used a lot and should therefore
> > have as little syntactic overhead as possible. And I think the short
> > syntax is also easier to read and write.
> >
> > A patch for the parser is trivial and is attached for Zend2.
> >
> > Note: I checked the newsgroup archive but couldn't find a discussion
> > about this. After not hearing back about my proposed enhancement to
> > debug_backtrace() and the dangling comma for function call parameters
> > being rejected I wonder if I'm using the right mailing list for this :-)
> >
> > - Chris
> >
> >
> > ------------------------------------------------------------------------
> >
> > Index: Zend/zend_language_parser.y
> > ===================================================================
> > RCS file: /repository/ZendEngine2/zend_language_parser.y,v
> > retrieving revision 1.127
> > diff -u -r1.127 zend_language_parser.y
> > --- Zend/zend_language_parser.y 19 Oct 2003 08:38:48 -0000 1.127
> > +++ Zend/zend_language_parser.y 4 Nov 2003 23:32:12 -0000
> > @@ -581,6 +581,7 @@
> >  | '@' { zend_do_begin_silence(&$1 TSRMLS_CC); } expr

zend_do_end_silence(&$1 TSRMLS_CC); $$ = $3; }

Ilia A.

22 years ago

I do not like the new syntax at all. If anything it seems rather unnatural and
what do you save, typing of 5 characters that makes it clear that this is an
array to even the most novice of users? It certainly not going to make the
code any faster and if anything will only add confusion.

Firm -1.

Ilia

Magnus Maatta

22 years ago

On Wed, 5 Nov 2003 08:06:53 -0500
Ilia Alshanetsky <ilia@prohost.org> wrote:

> I do not like the new syntax at all. If anything it seems rather unnatural and > what do you save, typing of 5 characters that makes it clear that this is an
> array to even the most novice of users? It certainly not going to make the
> code any faster and if anything will only add confusion.
>
> Firm -1.

I totally agree with Ilia.
And it doesn't take more than 0.4 seconds to type "array" anyway.


array("My 0.2c, " => "Magnus");

--
What does it mean if there is no fortune for you?

Derick Rethans

22 years ago

On Wed, 5 Nov 2003, Ilia Alshanetsky wrote:

> I do not like the new syntax at all. If anything it seems rather unnatural and
> what do you save, typing of 5 characters that makes it clear that this is an
> array to even the most novice of users? It certainly not going to make the
> code any faster and if anything will only add confusion.
>
> Firm -1.

Right, one point of confusion is using [] both for initialising array
and indexing them. I'm -1 on this too, array() and range() wosk fine.

Derick

--
"Interpreting what the GPL actually means is a job best left to those
that read the future by examining animal entrails."
-------------------------------------------------------------------------
Derick Rethans                                 http://derickrethans.nl/
International PHP Magazine                          http://php-mag.net/
-------------------------------------------------------------------------

Jani Taskinen

22 years ago

On Wed, 5 Nov 2003, Ilia Alshanetsky wrote:

>I do not like the new syntax at all. If anything it seems rather unnatural and
>what do you save, typing of 5 characters that makes it clear that this is an
>array to even the most novice of users? It certainly not going to make the
>code any faster and if anything will only add confusion.
>
>Firm -1.

There's enough magic already..I could say +1 if magic_quotes_*
is removed and everything is made case-sensitive first. :)

--Jani

Steph

22 years ago

OK .. I'm a wobbler.

I think it would be cool to have the cleaner alternative syntax; I think I'd
use it *in some situations and not others*, and I think that that in itself
would make my code virtually unmaintainable by anyone else.

As Andi originally said, having more than one way to do things isn't always
a good thing.

Add me to the -1 list.  Even tho' it's a cool idea.

- Steph