Syntactic improvement to array

Marcus Börger

19 years ago

Hello Andi,

it is a bit harder to read and not the php way imo.

best regards
marcus

Sunday, February 4, 2007, 8:25:22 AM, you wrote:

> Hi,

> I thought I may have brought this up a long time ago but couldn't find anything in the archives.
> For a long time already I've been thinking about possibly adding a new
> syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to do
> things, I think it'd look much more elegant especially (but
> not only) for nested arrays.

> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]

> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)

> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as it's
> not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.

> Andi

Best regards,
Marcus

Lukas Kahwe Smith

19 years ago

Marcus Boerger wrote:

> Hello Andi,
>
>   it is a bit harder to read and not the php way imo.

I agree with Marcus.

regards,
Lukas

Rasmus Lerdorf

19 years ago

Marcus Boerger wrote:

>   it is a bit harder to read and not the php way imo.

The PHP way is to steal and borrow from other languages whenever
possible to produce a syntax that is clear and understandable to people
doing web development.

What is clear and understandable to web developers is a moving target.
As someone mentioned, nobody who does any sort of web development today
can ignore Javascript and they will typically be switching back and
forth between Javascript and PHP every couple of minutes.  This is our
target user these days and as such this syntax is appropriate I think.

-Rasmus

phpxcache

19 years ago

> I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.

it sure acceptable for php users and will never be a conflict to "php way"
php is mean to be used for web pages in the first place, most ppl who
works on web pages have to know what javascript is, so there isn't any
difficulty for ppl to get used to either read or code []
btw, "ppl use json in instead of xml" may (or may not) be a good
example to this topic

Brian Moon

19 years ago

phpxcache wrote:

> most ppl who works on web pages have to know what javascript
> is, so there isn't any difficulty for ppl to get used ...

You give brand new PHP hackers too much credit.  Sure professional PHP
developers do have to work with Javascript.  But, working on Phorum and
see real users who are trying to hack their way around PHP, I can tell
you, they don't have a clue what they are doing.  $a = [1,2,3]; would
not mean jack sqat to those folks.  And as stated, finding docs on that
syntax would not be easy.  I tried finding the docs on the back tick
syntax the other day and had a hard time.  And I know what it does.  I
finally had to go look up exec() and hope some good doc writer (thanks,
whoever that was) had linked the back tick syntax there.

-1 for confusing new PHP users.

--

Brian Moon
-------------
http://dealnews.com/
It's good to be cheap =)

Stanislav Malyshev

19 years ago

> you, they don't have a clue what they are doing.  $a = [1,2,3]; would
> not mean jack sqat to those folks.  And as stated, finding docs on that

How hard can that be? If one is smart enough to do computer programming,
how hard can it be to know $a=[1,2,3] is an array? Like, what else could
it be?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Brian Moon

19 years ago

Stanislav Malyshev wrote:

>> you, they don't have a clue what they are doing.  $a = [1,2,3]; would
>> not mean jack sqat to those folks.  And as stated, finding docs on that
>
> How hard can that be? If one is smart enough to do computer programming,
> how hard can it be to know $a=[1,2,3] is an array? Like, what else could
> it be?
>

When a new PHP user asks you "What is an array?" you will understand.
Its clear that not all the folks on internals have actually spoken to
the masses of users whose first language is PHP.  People don't start
with BASIC and Pascal anymore.  That is why it has gotten so popular.
Someone who has never programmed before can pick it up and start hacking.

Don't even try explaining a ternary to them. =)

--

Brian Moon
-------------
http://dealnews.com/
It's good to be cheap =)

Stanislav Malyshev

19 years ago

> When a new PHP user asks you "What is an array?" you will understand.

If someone is not familiar with the concept of the array at all, it
doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
what we are discussing right now.

> Its clear that not all the folks on internals have actually spoken to
> the masses of users whose first language is PHP.  People don't start

As opposed to you who did, I presume. So, judging from your experience,
how it is different? How explaining array written as [] so much harder
that explaining array written as ()? What exactly constitutes the problem?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Brian Moon

19 years ago

> If someone is not familiar with the concept of the array at all, it
> doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
> what we are discussing right now.

My point is that if its written array(1,2,3) that have something to
search for in the docs.  The new proposed syntax removes that keyword
that a user can use to find the help they need.  As I said, back ticks,
as well as ternary, both suffer from this problem.  I see no reason to
add another hurdle for new users when there is no clear advantage to
this new syntax.  And, IMO, clear means that a majority of people think
its a no brainer.  I would say right now we have nothing of the sort.

--

Brian Moon
-------------
http://dealnews.com/
It's good to be cheap =)

Andrei Zmievski

19 years ago

I don't buy the "searching docs is easier" argument. There are plenty
of operators and such that are hard to search for.

-Andrei

On Feb 5, 2007, at 11:07 AM, Brian Moon wrote:

Brian Moon

19 years ago

Andrei Zmievski wrote:

> I don't buy the "searching docs is easier" argument. There are plenty of
> operators and such that are hard to search for.

Good point, but, were there pre-existing solutions to those operators
when they were created?  I think that is the point that Zeev was making.
We have a way to do this that is 95% the same as this new method.  If
this was a new language construct the discussion would be totally different.

--

Brian Moon
-------------
http://dealnews.com/
It's good to be cheap =)

Richard Lynch

19 years ago

On Mon, February 5, 2007 1:18 pm, Andrei Zmievski wrote:

> I don't buy the "searching docs is easier" argument. There are plenty
> of operators and such that are hard to search for.

Yes, and it makes life miserable for some of us...

Is that a good reason to extend that misery to yet another operator?

If the 'array' syntax bugs one that much, write a parser in PHP for
the [] syntax and load the giant arrays with that. :-) :-) :-)

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Andrei Zmievski

19 years ago

On Feb 5, 2007, at 3:37 PM, Richard Lynch wrote:

> Yes, and it makes life miserable for some of us...
>
> Is that a good reason to extend that misery to yet another operator?

Richard, please. This is not advanced OO stuff or anything close.
It's an operator. Give PHP users (even newbies) some credit.

-Andrei

Richard Lynch

19 years ago

On Mon, February 5, 2007 12:24 pm, Stanislav Malyshev wrote:

>
>> When a new PHP user asks you "What is an array?" you will
>> understand.
>
> If someone is not familiar with the concept of the array at all, it
> doesn't matter if it's written as array(1,2,3) or [1,2,3]. That's not
> what we are discussing right now.
>
>> Its clear that not all the folks on internals have actually spoken
>> to
>> the masses of users whose first language is PHP.  People don't start
>
> As opposed to you who did, I presume. So, judging from your
> experience,
> how it is different? How explaining array written as [] so much harder
> that explaining array written as ()? What exactly constitutes the
> problem?

Here's the difference:

You can Google for 'array' and learn a lot.

If you try to Google for [] you don't learn squat.

Try it and see.

So our 'newbie' at least has a good chance of figuring out array(1, 2,
3) on their own.  They've got must worse odds of figuring out [1,2,3]

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Tullio Andreatta ML

19 years ago

>> how it is different? How explaining array written as [] so much harder
>> that explaining array written as ()? What exactly constitutes the
>> problem?
>
> Here's the difference:
>
> You can Google for 'array' and learn a lot.
>
> If you try to Google for [] you don't learn squat.
>
> Try it and see.
>
> So our 'newbie' at least has a good chance of figuring out array(1, 2,
> 3) on their own.  They've got must worse odds of figuring out [1,2,3]

Ok. So I propose more "searcheable" operators:

let($i, 1)                 ===     $i = 1
let($d, add($a, $b, $c))   ===     $d = $a + $b + $c
call(foo, $arg1, $arg2)    ===     foo($arg1, $arg2)

:-)

Our 'newbie' at least has a good chance of figuring out
$a = [1,2,3]          vs.        $a = array(1,2,3)
is different than
$a = foobar(1,2,3)

--
Tullio Andreatta

Disclaimer: "Please treat this email message in a reasonable way, or we
might get angry" ( http://www.goldmark.org/jeff/stupid-disclaimers )

Lars Schultz

19 years ago

Hi.

> Our 'newbie' at least has a good chance of figuring out
>    $a = [1,2,3]          vs.        $a = array(1,2,3)
> is different than
>    $a = foobar(1,2,3)

I am probably out of my depth here...but I actually find the argument
about wether to introduce this syntax or not, very entertaining...it's a
classic example of human individuality. great really;)

The argument against introducing the new syntax, that says, that it's
less searchable,...well...why not improve the search functionality of
the php-documentation? it would help with all the other operators (and
magic functions and language constructs) if the search-function would
try to match the search-input against operators and constructs, no? I
know that google won't show anything worthwhile when queried about "php
[]" or the like...but...the php-documentation is very good and maybe we
could improve access to it...a newbie could then query all he wants in
the php-doc page. No good?

Lars

Robert Cummings

19 years ago

On Mon, 2007-02-05 at 10:01 -0800, Stanislav Malyshev wrote:

> > you, they don't have a clue what they are doing.  $a = [1,2,3]; would
> > not mean jack sqat to those folks.  And as stated, finding docs on that
>
> How hard can that be? If one is smart enough to do computer programming,
> how hard can it be to know $a=[1,2,3] is an array? Like, what else could
> it be?

The same argument can be made about how hard it is to understand

$a = array( 1, 2, 3 ).

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Stanislav Malyshev

19 years ago

>     $a = array( 1, 2, 3 ).
>

It's not hard. I don't think anybody ever argued it's hard to
understand. The argument was it's too verbose once you talk about
multi-dimensional arrays with a lot of sub-arrays containing in turn
even more sub-arrays - entire code becomes packed with repetitions of
"array" word.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Richard Lynch

19 years ago

On Mon, February 5, 2007 12:01 pm, Stanislav Malyshev wrote:

>> you, they don't have a clue what they are doing.  $a = [1,2,3];
>> would
>> not mean jack sqat to those folks.  And as stated, finding docs on
>> that
>
> How hard can that be? If one is smart enough to do computer
> programming,
> how hard can it be to know $a=[1,2,3] is an array? Like, what else
> could
> it be?

Looks like a syntax error to me. :-v

I wouldn't know if it was an array or something entirely new.

Could be a random selection from those choices.

Might be an ordered set, though I suppose in PHP that has to be an
array anyway, at least today.

Put it this way:  Are you willing to answer EVERY PHP-General question
asking what this is? ;-)

Cuz I'm sure not willing to do it.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Stanislav Malyshev

19 years ago

> Put it this way:  Are you willing to answer EVERY PHP-General question
> asking what this is? ;-)
>
> Cuz I'm sure not willing to do it.

I'm not willing to answer newbie questions on regular basis, but that
has nothing to do with anything - I was unwilling to do it with any
syntax. I just think inability of the users to comprehend a concept such
complicated as two brackets put around the array is grossly exaggerated.
If you figured out how to use <? ?>, you can figure out how to use [] ;)

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Pierre Joye

19 years ago

Hi Andi,

On 2/4/07, Andi Gutmans <andi@zend.com> wrote:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't find anything in the archives.
> For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.

I like this syntax, it is clear and easy to write. All other languages
use this syntax already (using either {} or [] but same principle) and
it can be done while keeping the classic array() definition. No need
to mention the numerous requests to add it to php.

--Pierre

Edin Kadribasic

19 years ago

I like it :)
+1

Edin

On Feb 4, 2007, at 8:25, Andi Gutmans wrote:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't find
> anything in the archives.
> For a long time already I've been thinking about possibly adding a new
> syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to
> do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as
> it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but
> I'd have to dive a bit deeper.
>
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
>

--
Edin Kadribasic, Emini A/S
Symbion Science Park, Fruebjergvej 3
DK-2100 Copenhagen Ø, Denmark
Phone: +45 3917 8335
Mobile: +45 228 226 11
edink@emini.dk

Johannes Schlueter

19 years ago

Hi Andi,

I'd like such a syntax enhancement.

These should be the results from the last time the issue was discussed:
http://devzone.zend.com/node/view/id/1474#Heading7

If I remember correct the main issues stated against it were
- it's to perlish
- Without keyword it's hard to find the documentation if you don't know
that syntax

But I would still like having it :-)

johannes

On Sat, 2007-02-03 at 23:25 -0800, Andi Gutmans wrote:

Nico Haase

19 years ago

Hallöchen,
*Johannes Schlüter* schrub:

>  - Without keyword it's hard to find the documentation if you don't know
>    that syntax

Well, this is the same with HEREDOC since you can use any delimiter.
And this new array-syntax should not replace the old one, but extend
it, so everyone who wants to be able to read his code, can use array()
furthermore.
Nico

--
www.buchtips.net - Rezensionen online

Hannes Magnusson

19 years ago

On 2/4/07, Nico Haase <nico.haase@gmx.de> wrote:

> Hallöchen,
> *Johannes Schlüter* schrub:
> >  - Without keyword it's hard to find the documentation if you don't know
> >    that syntax
>
> Well, this is the same with HEREDOC since you can use any delimiter.

http://php.net/<<<

-Hannes

Richard Lynch

19 years ago

On Sun, February 4, 2007 7:53 am, Hannes Magnusson wrote:

> On 2/4/07, Nico Haase <nico.haase@gmx.de> wrote:
>> Hallöchen,
>> *Johannes Schlüter* schrub:
>> >  - Without keyword it's hard to find the documentation if you
>> don't know
>> >    that syntax
>>
>> Well, this is the same with HEREDOC since you can use any delimiter.
>
> http://php.net/<<<

I'm pretty sure the Dev Team could manage to make these work:
http://php.net/[
http://php.net/[]
as well.

That presumes a user is brave enough to try to USE that URL.

There's not much we can do about email clients refusing to make that
bogus URL actually work as a hot link, however...

Yes -- I did just argue against my own position, but I'd rather have
valid arguments than hurt PHP.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Christian Schneider

19 years ago

Andi Gutmans wrote:

> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]

I like this syntax, more conscise but still clear (and well established
in other languages by now).

Two more thoughts (but please don't kill Andi's proposal because of it,
rather dismiss my comments instead ;-)):
- [$a, $b, $c] = ...    equivalent to    list($a, $b, $c) = ...
- func('foo' => $foo, 'bar' => $bar, ...)   equivalent to
func(array('foo' => $foo, 'bar' => $bar, ...), see
http://cschneid.com/php/ for more info

Regards,
- Chris

Richard Lynch

19 years ago

On Sun, February 4, 2007 8:23 am, Christian Schneider wrote:

> Andi Gutmans wrote:
>> So what I'm thinking of is:
>> array(1, 2, 3) == [1, 2, 3]
>
> I like this syntax, more conscise but still clear (and well
> established
> in other languages by now).
>
> Two more thoughts (but please don't kill Andi's proposal because of
> it,
> rather dismiss my comments instead ;-)):
> - [$a, $b, $c] = ...    equivalent to    list($a, $b, $c) = ...

Ewwwwwwww!

So now we have an invisible operator with a magical symbol '[' which
*sometimes* means create an array, but *sometimes* means to
de-construct an array into individual variables?

That's just disgusting, imho.

-1 !!!

> - func('foo' => $foo, 'bar' => $bar, ...)   equivalent to
> func(array('foo' => $foo, 'bar' => $bar, ...), see
> http://cschneid.com/php/ for more info

Again, saving 5 characters just to confuse the hell out of idiots like
me does not seem like a "win" for PHP. :-v

-1

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Christian Schneider

19 years ago

Richard Lynch wrote:

> So now we have an invisible operator with a magical symbol '[' which
> *sometimes* means create an array, but *sometimes* means to
> de-construct an array into individual variables?

The distinction you are making is from an implementation point of view.
From a language users point of view you're just dealing with arrays.
Some people consider the distinction of the two a feature, some consider
it a bug.

> That's just disgusting, imho.

To me it makes array usage more orthogonal and hence simpler, but that's
obviously a matter of taste.

What's also beautiful about [] IMHO is the symmetry of the syntax,
list() and array() are asymmetrical which I always found inferior.

>> - func('foo' => $foo, 'bar' => $bar, ...)   equivalent to
>> func(array('foo' => $foo, 'bar' => $bar, ...), see
>> http://cschneid.com/php/ for more info
>
> Again, saving 5 characters just to confuse the hell out of idiots like
> me does not seem like a "win" for PHP. :-v

It is NOT about saving characters. If is about less clutter. The more
important saving for us is the removal of an additional pair of parens
which look like line-noise when nested. Funnily enough I forgot the
closing parens of array() in my example above :-)

I agree that our function call syntax is somewhat magical as it
automatically starts and stops the array-composition when encountering
key => value pairs so I wasn't really expecting much love for this from
the list. But one can dream :-)

Anyway, back to the main topic: I'm surprised how much hate a syntactic
change like the one proposed by Andi still provokes nowadays when well
established languages like C, C++, Javascript, Python and Ruby seem to
successfully use [] or {} to construct arrays.

My personal summary of this thread is: We won't have syntactic sugar for
common things like arrays, named parameter emulation and the like ever
because it will be killed by the "we already have a way of doing this"
and the "you cannot look it up" argument. Shame, that would be the tiny
language development I'd personally benefit from.

Regards,
- Chris

Lukas Kahwe Smith

19 years ago

Christian Schneider wrote:

> My personal summary of this thread is: We won't have syntactic sugar for
> common things like arrays, named parameter emulation and the like ever
> because it will be killed by the "we already have a way of doing this"
> and the "you cannot look it up" argument. Shame, that would be the tiny
> language development I'd personally benefit from.

Named parameters is not just syntax sugar, as they would make it
possible to get compiler errors and phpoc support automatically over
having to implement some array based solution to trigger errors and some
other formatting standard for phpdoc. Then again we had this discussion
before as well, and unfortunately it was shot down (IIRC mainly because
people to think that named parameters should then be implemented for all
existing functions as well, which would be too much work .. then again
unicode conversion might (have been) the perfect time to do this).

regards,
Lukas

Christian Schneider

19 years ago

Lukas Kahwe Smith wrote:

> Named parameters is not just syntax sugar, as they would make it
> possible to get compiler errors and phpoc support automatically over
> having to implement some array based solution to trigger errors and some

Not 'our' way of named parameters where the main feature is the var-args
like behaviour of the parameter list, i.e. being able to pass in
"unknown" parameters. Useful for e.g. HTML generation or DB queries
where you can then map parameter names to HTML attributes or DB fields
respectively. So they are effectively an associative array and syntactic
sugar was good enough for us.

But that's a completely different direction than the and more more
strict way PHP is heading (PPP, typehints, ...) so The List(tm) won't
like ;-)

- Chris

LAUPRETRE François (P)

19 years ago

> From: Christian Schneider [mailto:cschneid@cschneid.com]

> What's also beautiful about [] IMHO is the symmetry of the syntax,
> list() and array() are asymmetrical which I always found inferior.

Agree. +1 for me, especially for this reason, even after reading Greg's examples :) IMO, it is
more important to provide an elegant alternative to list() than a new syntax for array().

>
> >> - func('foo' => $foo, 'bar' => $bar, ...)   equivalent to
> >> func(array('foo' => $foo, 'bar' => $bar, ...)

Argh! Reading such a line, I think of named parameters, not an array. Ugly, confusing. -1 for
me. Definitely.

May I add that, as I regularly write multi-layer arrays as SOAP return values, I personnaly
like this proposed syntax.

Francois

Unnamed Person

19 years ago

That would be very handy. As I code frequently JavaScript and ActionScript, I will use this feature
with pleasure. +2 for me :D The array(), especially for more-than-1 dimensional arrays is very
cumbersome.

Best Regards,
Ivailo Karamanolev

On Monday, February 5, 2007, 12:53:44 PM, LAUPRETRE François<francois.laupretre@ratp.fr> wrote:

Richard Quadling

19 years ago

On 05/02/07, LAUPRETRE François (P) <francois.laupretre@ratp.fr> wrote:
> > From: Christian Schneider [mailto:cschneid@cschneid.com]
> > >> - func('foo' => $foo, 'bar' => $bar, ...)   equivalent to
> > >> func(array('foo' => $foo, 'bar' => $bar, ...)
>
> Argh! Reading such a line, I think of named parameters, not an array. Ugly, confusing. -1 for
> me. Definitely.

I agree with Francois here. Other than looking STRONLY like named
parameters, surely there is a flaw if a declaration is ...

function convert(array $from, array $to)

If the calling code is ...

convert('foo' => $foo, 'bar' => $bar, ...)

where is the boundaries for the 2 arrays?

There would need to be SOMETHING.



convert('foo'


-- 
-----
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"

Christian Schneider

19 years ago

Richard Quadling wrote:

>> Argh! Reading such a line, I think of named parameters, not an array.

That's exactly what we are emulating this way ;-)

> I agree with Francois here. Other than looking STRONLY like named
> parameters, surely there is a flaw if a declaration is ...
>
> function convert(array $from, array $to)
>
> If the calling code is ...
>
> convert('foo' => $foo, 'bar' => $bar, ...)
>
> where is the boundaries for the 2 arrays?

Our patch is greedy, i.e. it collects as much as possible into one
array. If you want to do this you need an explicit array() on the second
set of parameters. That's magical, non-obvious and evil but we tend to
have one $p array for all named parameters only, why would you want more
than one parameter here anyway? ;-)

But I realize that's too much off the beaten path for The List and I'm
not even sure why I mentioned it. So please ignore it and go back to
Andi's proposal :-)

- Chris

LAUPRETRE François (P)

19 years ago

> From: Christian Schneider [mailto:cschneid@cschneid.com]

> >> Argh! Reading such a line, I think of named parameters,
> not an array.
>
> That's exactly what we are emulating this way ;-)

> Our patch is greedy, i.e. it collects as much as possible
> into one array. If you want to do this you need an explicit
> array() on the second set of parameters. That's magical,
> non-obvious and evil but we tend to have one $p array for all
> named parameters only, why would you want more than one
> parameter here anyway? ;-)

OK. I didn't understand that it was a way to pass a list of pseudo-named parameters.

But, even if it adds 2 chars, in such a case, I still prefer:

Convert(['foo' => $foo, 'bar' => $bar, ... ]);

Regards

Francois

Andrei Zmievski

19 years ago

On Feb 4, 2007, at 8:52 PM, Richard Lynch wrote:

> Ewwwwwwww!
>
> So now we have an invisible operator with a magical symbol '[' which
> *sometimes* means create an array, but *sometimes* means to
> de-construct an array into individual variables?
>
> That's just disgusting, imho.
>
> -1 !!!

The way I view [] is that it creates an array "context". When the
context is an RHS, it instantiates an array. When it's an LHS, the
context deconstructs the array.

-Andrei

Todd Ruth

19 years ago

Would this be legal?

function f() {
return [ 1, 2 ];
}

$x = [ $a, $b ] = f();

In the end, would we have...?
$a = 1;
$b = 2;
$x = array(1,2);

I'm not trying to be positive or negative about the
syntax.  I'm just "testing" somewhat edge cases.

- Todd

On Mon, 2007-02-05 at 10:06 -0800, Andrei Zmievski wrote:
...

Andrei Zmievski

19 years ago

Good question. If it's possible to make it behave this way, I don't see
why not. On the other hand, if you take list(), it can't be used in
RHS.

-Andrei

On Feb 5, 2007, at 10:28 AM, Todd Ruth wrote:

Sara Golemon

19 years ago

I would argue that list() (and [] when used like list()) should remain a
terminal expression.  Yes it's possible to make it non-terminal, but I
don't like what the resulting syntax winds up looking like.

-Sara

Richard Lynch

19 years ago

On Mon, February 5, 2007 12:06 pm, Andrei Zmievski wrote:

> On Feb 4, 2007, at 8:52 PM, Richard Lynch wrote:
>
>> Ewwwwwwww!
>>
>> So now we have an invisible operator with a magical symbol '[' which
>> *sometimes* means create an array, but *sometimes* means to
>> de-construct an array into individual variables?
>>
>> That's just disgusting, imho.
>>
>> -1 !!!
>
> The way I view [] is that it creates an array "context". When the
> context is an RHS, it instantiates an array. When it's an LHS, the
> context deconstructs the array.

I can 'splain list() to a newbie and get them to understand it as an
array deconstructor function thingie, and usually succeed in one or
two tries to get it into their heads.

I don't think I can do that with [] and LHS and RHS in anything like 2
tries...  More like 10 times, probably.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Andrei Zmievski

19 years ago

That's because you wouldn't be using those words with a newbie, if
you are smart. You'd simply say "it works like list() here" and "it
works like array()" here.

-Andrei


On Feb 5, 2007, at 3:41 PM, Richard Lynch wrote:

Stanislav Malyshev

19 years ago

> So now we have an invisible operator with a magical symbol '[' which
> *sometimes* means create an array, but *sometimes* means to
> de-construct an array into individual variables?

Yep. We also have an invisible magical operator (), which sometimes
means function definition, sometimes means expression grouping,
sometimes means delimiter, sometimes means function call and sometimes
means regular expression grouping. How do we manage? ;)

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Richard Lynch

19 years ago

On Mon, February 5, 2007 12:05 pm, Stanislav Malyshev wrote:

>> So now we have an invisible operator with a magical symbol '[' which
>> *sometimes* means create an array, but *sometimes* means to
>> de-construct an array into individual variables?
>
> Yep. We also have an invisible magical operator (), which sometimes
> means function definition, sometimes means expression grouping,
> sometimes means delimiter, sometimes means function call and sometimes
> means regular expression grouping. How do we manage? ;)

How you manage is that a zillion newbies use:

include("foo.inc");
echo("foo.inc");

and they don't even realize that the () doesn't mean what they think
it means, and it "just works" because it's a no-op.

*THAT* is harder to explain than just about anything in PHP syntax.

How many newbies will be trying:
array[1, 2, 3];
and left scratching their heads when it doesn't work?

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Robert Cummings

19 years ago

On Mon, 2007-02-05 at 17:46 -0600, Richard Lynch wrote:

>
> On Mon, February 5, 2007 12:05 pm, Stanislav Malyshev wrote:
> >> So now we have an invisible operator with a magical symbol '[' which
> >> *sometimes* means create an array, but *sometimes* means to
> >> de-construct an array into individual variables?
> >
> > Yep. We also have an invisible magical operator (), which sometimes
> > means function definition, sometimes means expression grouping,
> > sometimes means delimiter, sometimes means function call and sometimes
> > means regular expression grouping. How do we manage? ;)
>
> How you manage is that a zillion newbies use:
>
> include("foo.inc");
> echo("foo.inc");
>
> and they don't even realize that the () doesn't mean what they think
> it means, and it "just works" because it's a no-op.

It's not a no-op, I'm sure it actually applies parenthesis precedence on
the expression "foo.inc" :) Personally, I use the parenthesis when using
include and require because I prefer it that way... though I don't doubt
some newbies think it's a function *heh*.

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Edin Kadribasic

19 years ago

On Feb 6, 2007, at 0:46, Richard Lynch wrote:

> and they don't even realize that the () doesn't mean what they think
> it means, and it "just works" because it's a no-op.

() is not a no-op.

return ($a) vs. return $a could cause PHP to corrupt memory and crash :)

Edin

--
Edin Kadribasic, Emini A/S
Symbion Science Park, Fruebjergvej 3
DK-2100 Copenhagen Ø, Denmark
Phone: +45 3917 8335
Mobile: +45 228 226 11
edink@emini.dk

LAUPRETRE François (P)

19 years ago

> From: Richard Lynch
>
> How many newbies will be trying:
> array[1, 2, 3];
> and left scratching their heads when it doesn't work?

Yes, even if I am in favor of the [] syntax, it is a good argument: 'array[ 1, 2, 3]' can
become a very common error, and not especially among newbies!

Maybe I am wrong, but would it be possible to accept all these syntaxes :

array(1, 2, 3)  (RHS only)
[ 1, 2, 3 ]     (RHS=array / LHS=list, I especially like: '$x = [ $a, $b ] = f()' :)
list($a, $b)    (LHS only)
array[1, 2, 3]  (RHS only)

For this purpose, we could say that the [] notation is optionally preceded by 'array'.

Another idea if you want to make it easier to understand for newbies: make array() and list()
synonyms, so that array() behaves as list() when LHS, and list() behaves as array() when RHS.
IMHO, it would become simpler to explain.

If we implement both, we can even suppport 'list[ 1, 2, 3 ]'. How can we be more permissive?

Regards

Francois

Richard Lynch

19 years ago

On Tue, February 6, 2007 8:17 am, LAUPRETRE François (P) wrote:

>> From: Richard Lynch
>>
>> How many newbies will be trying:
>> array[1, 2, 3];
>> and left scratching their heads when it doesn't work?
>
> Yes, even if I am in favor of the [] syntax, it is a good argument:
> 'array[ 1, 2, 3]' can
> become a very common error, and not especially among newbies!
>
> Maybe I am wrong, but would it be possible to accept all these
> syntaxes :
>
> array(1, 2, 3)  (RHS only)
> [ 1, 2, 3 ]     (RHS=array / LHS=list, I especially like: '$x = [ $a,
> $b ] = f()' :)
> list($a, $b)    (LHS only)
> array[1, 2, 3]  (RHS only)
>
> For this purpose, we could say that the [] notation is optionally
> preceded by 'array'.
>
> Another idea if you want to make it easier to understand for newbies:
> make array() and list()
> synonyms, so that array() behaves as list() when LHS, and list()
> behaves as array() when RHS.
> IMHO, it would become simpler to explain.
>
> If we implement both, we can even suppport 'list[ 1, 2, 3 ]'. How can
> we be more permissive?

I probably needn't even post this, but:

-1

Having even more ways to do everything is just confusing, not handy.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Hannes Magnusson

19 years ago

Hi Andi

function typeHinted([] $array = []) { // type hint array, default to empty one
if(count($array)) {
array_merge($array, ["foo" => []]); // merge $array with
array("foo" => array());
return $array;
}
return []; // empty array
}

typeHinted([1 => [1 => []]]); // array(1 => array(1 => array()));

-1 from me

-Hannes

On 2/4/07, Andi Gutmans <andi@zend.com> wrote:

Christian Schneider

19 years ago

Hannes Magnusson wrote:

> typeHinted([1 => [1 => []]]); // array(1 => array(1 => array()));

IMHO the common case would benefit and your pathological example is
unreadable both ways. Personally I'd reformat it to

typeHinted([
1 => [
1 => []
]
]);

resp.

typeHinted(array(
1 => array(
1 => array(),
)
));

or something similar anyway to make them readable. Plus you could still
use array() if you really wanted to.

Regards,
- Chris

Richard Lynch

19 years ago

On Sun, February 4, 2007 8:58 am, Christian Schneider wrote:

> Plus you could
> still
> use array() if you really wanted to.

Yes, but sooner or later I am stuck with somebody else's code who
decided to write the non-array version, and I'm sitting there
wondering what [bleep] this code is doing.

This argument really never holds water.

I don't find that dropping 5 characters increases readability to any
large degree.

If readability of a complex structure is of paramount importance,
proper newlines and indentation are going to be required anyway, and
the 'array' bit is not relevant.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Pierre Joye

19 years ago

On 2/4/07, Hannes Magnusson <hannes.magnusson@gmail.com> wrote:

> Hi Andi
>
> function typeHinted([] $array = []) { // type hint array, default to empty one

That's a wrong example.

Type hinting should still rely on the literal name:

function typeHinted(Array $myarray=[])

--Pierre

Andi Gutmans

19 years ago

Yep. I should have finished reading my messages first :)

Andi Gutmans

19 years ago

I would definitely not advocate to use [] in a type hint. For the same reason you don't use array() but array :)
It'd be:
function typeHinted(array $array = []) {
...
}

I don't see any issue with that. I'm talking about the construct that allows you to create an array.
Andi

Zeev Suraski

19 years ago

My 2c - unless we also make it behave like a list() when in
assignment context - I think it will confusing.

So I'm +1 if we make it work as both list() and array(), and -1 otherwise.

Zeev

At 09:25 04-02-07, Andi Gutmans wrote:

Richard Lynch

19 years ago

On Sun, February 4, 2007 10:59 am, Zeev Suraski wrote:

> My 2c - unless we also make it behave like a list() when in
> assignment context - I think it will confusing.
>
> So I'm +1 if we make it work as both list() and array(), and -1
> otherwise.

Can you show by example what this means?

I'm seeing several different things in my head...

I don't like any of them, either. :-v

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Andrei Zmievski

19 years ago

I agree. Syntax is good, if we make it work both ways.

-Andrei

On Feb 4, 2007, at 8:59 AM, Zeev Suraski wrote:

Ilia A.

19 years ago

I have to second Marcus on this, this new syntax makes things harder
to read. I mean what are you saving here, a few letter?

Ilia

On 4-Feb-07, at 2:25 AM, Andi Gutmans wrote:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't
> find anything in the archives.
> For a long time already I've been thinking about possibly adding a
> new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way
> to do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as
> it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue
> but I'd have to dive a bit deeper.
>
> Andi
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>

Ilia Alshanetsky

Andi Gutmans

19 years ago

I think it's actually more readable especially for people coming from other languages.
I've always found the array() syntax not quite as readable as other languages because it allows for less structuring esp. with
nesting. I actually find it harder to digest despite it being more verbose (which in most cases is not the case).
It's definitely not about saving letters. I never favor saving typing unless there's a good reason. In this case I think it's just a
better syntax which we should have used from day 1.

Andi

Ilia A.

19 years ago

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.


On 4-Feb-07, at 12:39 PM, Andi Gutmans wrote:

> I think it's actually more readable especially for people coming
> from other languages.
> I've always found the array() syntax not quite as readable as other
> languages because it allows for less structuring esp. with
> nesting. I actually find it harder to digest despite it being more
> verbose (which in most cases is not the case).
> It's definitely not about saving letters. I never favor saving
> typing unless there's a good reason. In this case I think it's just a
> better syntax which we should have used from day 1.
>
> Andi
>
>> -----Original Message-----
>> From: Ilia Alshanetsky [mailto:ilia@prohost.org]
>> Sent: Sunday, February 04, 2007 9:28 AM
>> To: Andi Gutmans
>> Cc: internals@lists.php.net
>> Subject: Re: [PHP-DEV] Syntactic improvement to array
>>
>> I have to second Marcus on this, this new syntax makes things
>> harder to read. I mean what are you saving here, a few letter?
>>
>> Ilia
>>
>>
>> On 4-Feb-07, at 2:25 AM, Andi Gutmans wrote:
>>
>>> Hi,
>>>
>>> I thought I may have brought this up a long time ago but
>> couldn't find
>>> anything in the archives.
>>> For a long time already I've been thinking about possibly
>> adding a new
>>> syntax for array(...) which would be shorter. I'd suggest
>> [...]. While
>>> I am usually not in favor of having more than one way to do
>> things, I
>>> think it'd look much more elegant especially (but not only)
>> for nested
>>> arrays.
>>>
>>> So what I'm thinking of is:
>>> array(1, 2, 3) == [1, 2, 3]
>>> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
>> array("key"
>>> => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>>>
>>> $arr = [1, 2, 3]
>>> vs.
>>> $arr = array(1, 2, 3)
>>>
>>> Well enough examples given :)
>>> I think it's not worth doing unless there's overwhelming support as
>>> it's not desperately needed. But I'd be interested to hear people's
>>> thoughts. It seems implementation shouldn't be an issue but
>> I'd have
>>> to dive a bit deeper.
>>>
>>> Andi
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List To
>> unsubscribe,
>>> visit: http://www.php.net/unsub.php
>>>
>>
>> Ilia Alshanetsky
>>
>>
>>
>>
>

Ilia Alshanetsky

Pierre Joye

19 years ago

Hi,

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.

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.

--Pierre

Steph

19 years ago

> 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.
>
> 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.

And what about maintenance? And what about the confusion for beginners?

- Steph

Lukas Kahwe Smith

19 years ago

Steph wrote:

>> 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.
>>
>> 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.
>
> And what about maintenance? And what about the confusion for beginners?

Yes, you will come across it if its added.
I find the Javascript syntax confusing to read as well. However more
importantly I do not see the point in adding this sugar to save 5 chars.

@Andi: I dont quite understand your formatting argument really.

regards,
Lukas

Edin Kadribasic

19 years ago

Lukas Kahwe Smith wrote:

> Yes, you will come across it if its added.
> I find the Javascript syntax confusing to read as well. However more
> importantly I do not see the point in adding this sugar to save 5 chars.

Nested arrays become very unreadable with the current PHP syntax. I
think killing those 5 chars per array would actually make thing more
readable.

I don't find:

$a = [1 => ['pears', 'apples'], 2 => ['juice', 'oranges']];

any less readable than:

$a = array(1 => array('pears', 'apples'), 2 => array('juice', 'oranges'));

Quite the opposite actually :)

Edin

Derick Rethans

19 years ago

On Sun, 4 Feb 2007, Edin Kadribasic wrote:

> I don't find:
>
> $a = [1 => ['pears', 'apples'], 2 => ['juice', 'oranges']];
>
> any less readable than:
>
> $a = array(1 => array('pears', 'apples'), 2 => array('juice', 'oranges'));
>
> Quite the opposite actually :)

That's a personal thing, and I disagree. The array() syntax is clearer.

regards,
Derick

Robert Cummings

19 years ago

On Sun, 2007-02-04 at 19:38 +0100, Edin Kadribasic wrote:

> Lukas Kahwe Smith wrote:
> > Yes, you will come across it if its added.
> > I find the Javascript syntax confusing to read as well. However more
> > importantly I do not see the point in adding this sugar to save 5 chars.
>
> Nested arrays become very unreadable with the current PHP syntax. I
> think killing those 5 chars per array would actually make thing more
> readable.
>
>
> I don't find:
>
> $a = [1 => ['pears', 'apples'], 2 => ['juice', 'oranges']];
>
> any less readable than:
>
> $a = array(1 => array('pears', 'apples'), 2 => array('juice', 'oranges'));
>
> Quite the opposite actually :)

Depends on how you format multi-level arrays...

$a = array
(
1 => array
(
'pears',
'apples',
),
2 => array
(
'juice',
'organge',
),
);

In the new format...

$a =
[
1 =>
[
'pears',
'apples',
],
2 =>
[
'juice',
'organge',
],
];

Can't say that I see a terribly great advantage in readability.

-0 :)

Cheers,
Rob.

--
.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting  |
| a powerful, scalable system for accessing system services  |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for       |
| creating re-usable components quickly and easily.          |
`------------------------------------------------------------'

Mike Robinson

19 years ago

Pierre wrote:

> 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.
>
> 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.

I agree sir.

It's a nice little addition - all the better if it isn't too much
work to implement and someone has already volunteered to do it.  :)

Best Regards

Mike Robinson

Ilia A.

19 years ago

On 4-Feb-07, at 1:14 PM, Pierre wrote:

> 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.
>
> 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.

If you want to make PHP into Perl that's a fine goal I suppose,
however that's not something I want to participate in.

Ilia Alshanetsky

Lukas Kahwe Smith

19 years ago

Ilia Alshanetsky wrote:

> On 4-Feb-07, at 1:14 PM, Pierre wrote:
>
>> 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.
>>
>> 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.
>
> If you want to make PHP into Perl that's a fine goal I suppose, however
> that's not something I want to participate in.

For what its worth, I dont really see a good reason for this addition.
But its also not something I feel so strongly about that I really think
its critical. I am much more concerned about adding fatal errors for OO
strictness violations (ups .. i am about to high jack the thread to
bring up E_DEPRECATED again).

regards,
Lukas

Pierre Joye

19 years ago

On 2/4/07, Ilia Alshanetsky <ilia@prohost.org> wrote:

> On 4-Feb-07, at 1:14 PM, Pierre wrote:
>
> > 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.
> >
> > 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.
>
> If you want to make PHP into Perl that's a fine goal I suppose,
> however that's not something I want to participate in.

That's also hardly an argument as all modern languages support this
syntax as wel as an array-like one (in one form or another, using
constructors, initializer or special ops).

The argument "if you like to make PHP into <put your worst nightmare
here>" is getting old. We argue about OO and PHP using the same one,
goto is also such a victim  (the spaghetti code FUD).

This syntax has been asked hundred times in the past and we kept find
all possible excuses to ignore these requests.  I think we will make a
mistake if we ignore it once again.

No more cent for this thread :)

--Pierre

Marcus Börger

19 years ago

Hello Pierre,

as much as you are true we never accepted the argument that some simply
can skip a certain syntax or feature.

best regards
marcus

Sunday, February 4, 2007, 7:14:19 PM, you wrote:

> Hi,

> 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.

> 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.

> --Pierre

Best regards,
Marcus

Zeev Suraski

19 years ago

At 20:14 04-02-07, Pierre wrote:

>Hi,
>
>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.
>
>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.

We never believed in that approach and we're not about to start now :).

Zeev

Pierre Joye

19 years ago

On 2/4/07, Zeev Suraski <zeev@zend.com> wrote:

> At 20:14 04-02-07, Pierre wrote:
> >Hi,
> >
> >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.
> >
> >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.
>
> We never believed in that approach and we're not about to start now :).

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.

--Pierre

Zeev Suraski

19 years ago

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,
>> >
>> >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.
>> >
>> >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.
>>
>>We never believed in that approach and we're not about to start now :).
>
>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.

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.

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.

I think we can live w/o it like we did in the last decade, but I feel
strongly about not introducing it unless we also support [] as a
replacement for list().  If [] works for arrays people would expect
it to work for lists too.  I guess my more accurate vote for that
option would be +0 (and -1 in case it's only a replacement for array()).

Zeev

Pierre Joye

19 years ago

On 2/4/07, Zeev Suraski <zeev@zend.com> wrote:

> 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'.

We already have many ways to do the same tasks. It is getting even
worst as even some bugs require to use the other way to solve the
problem (like with arrays and __get/__set, it sometimes requires to
use ArrayObect and we even introduce a kind of breakage in 5.2.x...).

> 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.

It should have yes. And for most situations it did. But here we are
talking about something asked since years and always rejected with the
same arguments, despite a clear support from the community. We should
organize a poll somewhere, I will be surprised to see a negative
result.

> I think we can live w/o it like we did in the last decade, but I feel
> strongly about not introducing it unless we also support [] as a
> replacement for list().  If [] works for arrays people would expect
> it to work for lists too.  I guess my more accurate vote for that
> option would be +0 (and -1 in case it's only a replacement for array()).

It is impossible (holy BC) to replace array(), no question here  :)

--Pierre

Zeev Suraski

19 years ago

At 23:51 04-02-07, Pierre wrote:

>On 2/4/07, Zeev Suraski <zeev@zend.com> wrote:
>
>>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'.
>
>We already have many ways to do the same tasks.

I would argue that we don't compared to other languages of PHP's
age.  Either way it doesn't matter - it's still a guideline we should stick to.

To make it clear, the main thing I opposed is not the new idea (I
stated my opinion separately), but the notion of "you don't have to
use the new syntax so why should you care", which simply doesn't cut
it with PHP.

Zeev

Steph

19 years ago

>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.

FWIW, I'm with Ilia on this; I find it confusing too. There's been the same
syntax in PHP since the earliest days, why add another way to write it now?
Is there some material benefit, e.g. would it make it easier to work with
some third-party thing such as XML?

Stanislav Malyshev

19 years ago

IA>>I personally find array extremely clear, in recent weeks I had to do A
IA>>LOT of JavaScript work where the array syntax works in a manner you
IA>>suggest for PHP and its a massive pain. It does not make for a very

By pure coincidence, I was doing a bunch of javascript work lately too,
and I find [] syntax OK. From readability POV it's not much difference,
but much less clutter if you have really massive data array - no array()
things which take half of the space.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/

Steph

19 years ago

Hi Stas,

> By pure coincidence, I was doing a bunch of javascript work lately too,
> and I find [] syntax OK. From readability POV it's not much difference,
> but much less clutter if you have really massive data array - no array()
> things which take half of the space.

Fine, but in javascript there is only one option. That's the difference.

- Steph

Stefan Walk

19 years ago

Steph wrote:

> Hi Stas,
>
>> By pure coincidence, I was doing a bunch of javascript work lately
>> too, and I find [] syntax OK. From readability POV it's not much
>> difference, but much less clutter if you have really massive data
>> array - no array() things which take half of the space.
>
> Fine, but in javascript there is only one option. That's the difference.
>
> - Steph

a = Array(1,2,3)
a = [1,2,3]

It's the same as in php ...

Regards, Stefan

Steph

19 years ago

>> Fine, but in javascript there is only one option. That's the difference.
>>
>> - Steph
>
> a = Array(1,2,3)
> a = [1,2,3]

I stand corrected. Apologies for the noise.

- Steph

Richard Lynch

19 years ago

On Sun, February 4, 2007 2:46 pm, Stefan Walk wrote:

> Steph wrote:
>> Hi Stas,
>>
>>> By pure coincidence, I was doing a bunch of javascript work lately
>>> too, and I find [] syntax OK. From readability POV it's not much
>>> difference, but much less clutter if you have really massive data
>>> array - no array() things which take half of the space.
>>
>> Fine, but in javascript there is only one option. That's the
>> difference.
>>
>> - Steph
>
> a = Array(1,2,3)
> a = [1,2,3]

Apparently I missed the JS tutorial that you could use [1, 2, 3] cuz I
always just did it the PHP way...

Never been unhappy about it, except when I forget to Capitalize the
dang thing... :-)

I'm not planning on switching to the other syntax in JS either -- An
easy-to-find Caps error beats WTF any day, and to me, not having
'array' there is just a WTF.

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Derick Rethans

19 years ago

On Sat, 3 Feb 2007, Andi Gutmans wrote:

> I thought I may have brought this up a long time ago but couldn't find
> anything in the archives. For a long time already I've been thinking
> about possibly adding a new syntax for array(...) which would be
> shorter. I'd suggest [...]. While I am usually not in favor of having
> more than one way to do things, I think it'd look much more elegant
> especially (but not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :) I think it's not worth doing unless
> there's overwhelming support as it's not desperately needed. But I'd
> be interested to hear people's thoughts. It seems implementation
> shouldn't be an issue but I'd have to dive a bit deeper.

That gets a big -1 from me, unless you misposed this mail and it should
have ended up on internals@perl.org or something ;-)

regards,
Derick

Sara Golemon

19 years ago

> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>

An enthusiastic thumbs-sideways.

I'll probably use this at some point, but not for anything which needs
to be version agnostic.

-Sara

Richard Lynch

19 years ago

On Sun, February 4, 2007 1:25 am, Andi Gutmans wrote:

> I thought I may have brought this up a long time ago but couldn't find
> anything in the archives.
> For a long time already I've been thinking about possibly adding a new
> syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to
> do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as
> it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but
> I'd have to dive a bit deeper.

I somewhat prefer seeing 'array' there so I know what the [bleep] is
going on, personally.

-0.3

--
Some people have a "gift" link here.
Know what I want?
I want you to buy a CD from some starving artist.
http://cdbaby.com/browse/from/lynch
Yeah, I get a buck. So?

Greg Beaver

19 years ago

Andi Gutmans wrote:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't find anything in the archives.
> For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.

future:
<?php
$a = [1, 2, 3];
$a[1] = [1];
$a = [1];
[$a] = $a;
$a[] = [];
echo $a.[1]; // not a parse error
?>

now:
<?php
$a = array(1, 2, 3);
$a[1] = array(1);
$a = array(1);
list($a) = $a;
$a[] = array();
echo $a.[1]; // now a parse error
?>

For what it's worth, the examples above show why I'm a strong -1 on this
idea.  It introduces the possibility of weird misunderstandings that
just don't exist now, and also introduces a new way to accidentally
break your script that wasn't possible before.

The only way I could see solving this would be:

1) [] != list()
2) use a[] as in $a = a[1, 2, 3] but then we might as well stick with
array().

Either way, [] is overloaded in the new definition:

1) array access
2) ArrayAccess object offsetGet/offsetSet
3) incremental index ($a[] = 1;)
4) array creation
[5) list()]

Whereas now, it is only 3 possible meanings, all of which are consistent
with a few quirks in the ArrayAccess one as of PHP 5.2.

Greg

Antony Dovgal

19 years ago

On 02/04/2007 10:25 AM, Andi Gutmans wrote:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't find anything in the archives.
> For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.

It doesn't look more elegant to me.
-1

--
Wbr,
Antony Dovgal

Mathias Bank

19 years ago

Andi Gutmans schrieb:

> Hi,
>
> I thought I may have brought this up a long time ago but couldn't find anything in the archives.
> For a long time already I've been thinking about possibly adding a new syntax for array(...) which would be shorter. I'd suggest
> [...]. While I am usually not in favor of having more than one way to do things, I think it'd look much more elegant especially (but
> not only) for nested arrays.
>
> So what I'm thinking of is:
> array(1, 2, 3) == [1, 2, 3]
> array(1, 2, array("foo", "bar")) == [1, 2, ["foo", "bar"]]
> array("key" => 1, "key2" => 2) == ["key" => 1, "key2" => 2]
>
> $arr = [1, 2, 3]
> vs.
> $arr = array(1, 2, 3)
>
> Well enough examples given :)
> I think it's not worth doing unless there's overwhelming support as it's not desperately needed. But I'd be interested to hear
> people's thoughts. It seems implementation shouldn't be an issue but I'd have to dive a bit deeper.
>
> Andi

Well, this discussion is really a stupid discussion. Obviously, there
are some people, who likes this syntax ( in list() and array() form) but
there are some people, who dislike it.

But I have to ask: what's the matter. A good programming language should
not force the developer to program as the language wants. A good
programming language should support the developer in writing code he
likes, the way he likes.

Of course there could be problems with new developers. But the question
is: is this relevant?
- Should php as programming language only provide one syntax only
because new developers could have problems (or not, I don't think, that
would be a great problem, because in other languages, this syntax is
already usable).
- Should php only support one syntax so that every code is easier to
maintain (if this is your only problem with foreign code, you are a
really lucky guy!)

It don't think so: PHP is a good language, but writing code in PHP is
sometimes awful. This could be improved by an alternative syntax. This
could help new developers who are coming from another language. This
could make coding funnier for some developers.

So: what's the matter? The idea of [] does not harm existent code.
Everyone who does not like this syntax can avoid it in his code. But
please don't tell others how they have to write their code! Let them write!

Mathias

Hartmut Holzgraefe

19 years ago

Mathias Bank wrote:

> It don't think so: PHP is a good language, but writing code in PHP is
> sometimes awful. This could be improved by an alternative syntax. This
> could help new developers who are coming from another language. This
> could make coding funnier for some developers.

Alternative syntax is what makes reading someone else's Perl code
"funny" ... ;(

> So: what's the matter? The idea of [] does not harm existent code.
> Everyone who does not like this syntax can avoid it in his code.
> But please don't tell others how they have to write their code!
> Let them write!

This violates a simple but important principle:

The burden shall be on the writer, not the readers.

As long as you write code all by yourself and never share it in
any way your argument may hold true. The very second your code
needs to be read or even maintained by others alternative syntax
choices quickly become a nightmare. So you have to agree on one
form or the other and add yet another item to your coding style
rules list. So you even have to bother *more* about telling
others (or yourself) how to write code than you had to with only
one syntax alternative.

As a matter of taste i do prefer the [] alternative over the
current array()/list() approach. But we can't get rid of array()
or list() any time soon, even if we would decide to deprecate them
now in favor of []. So we're stuck with them and the nicer syntax
does not justify the can of worms opened by introducing an
alternative syntax for an already existing feature.

So if we were designing PHP today i'd be all for [] and [] only,
but as things are my vote is mostly against it even though i sort
of like the syntax.

So from my side a

-0.8

--
Hartmut Holzgraefe, Senior Support Engineer                            .
MySQL AB, www.mysql.com

Brian Moon

19 years ago

> But I have to ask: what's the matter. A good programming language should
> not force the developer to program as the language wants. A good
> programming language should support the developer in writing code he
> likes, the way he likes.

So, you are new to php internal huh? =)

Seriously, the language can not be adapted to every whim of every
developer.  Adding several ways to do things was fine when PHP was a
neat tool to mess around with.  Now people's paychecks depend on it.
IMO, it's a slippery slope to just add things because you can.

> This could be improved by an alternative syntax.

Ah, but not all see it as an improvement.  Peronsally, every time I see
this type of syntax in perl or javascript, I cringe.  Luckily I don't do
much perl.  When I see it in JS, I change it.

The funny thing is that Andi probably could have just commited this to
the PHP6 tree and made an announcement.  There would have been ~4
replies and it would have been over with.

--

Brian Moon
-------------
http://dealnews.com/
It's good to be cheap =)

Vlad Bosinceanu

19 years ago

I for one cringe when I see list(), and I'd love to see [$a, $b] =
array(...) become an alternative to that. Can't say I care that much
about an alternative syntax for dealing with array creation, but I
wouldn't mind.

"[]" already suggests "array", and I guess existing developers will have
no problem picking it up. Newbies would bump into the docs just as they
currently bump into the array section.

I don't see how an addition like this could affect people's paychecks.

V

Brian Moon wrote: