Object and Array Literals

14 years ago by Jordi Boggiano — view source

unread

Thanks for working on this.

Please read, and if you have a comment that is not already covered in the RFC, raise it here. I'm definitely open to discussion, but I would really love to keep this discussion civil.

TBH, I dropped half-way through the original topic, so I'm sorry if I
missed something, but why don't we just treat {"foo":"bar"} as an
array? json_decode() can do it, and it makes complete sense since PHP
arrays are hashes too. I don't see much benefit to having this create
an object by default, especially since even if you use that notation
to send data to a JSON API, json_encode'ing a hash will create an
object.

It's the only pain point I really have, that I can't use true
json-syntax without ending up with this messy pile of objects/arrays
mixed together. If we do this, IMO the hashes should not be able to be
defined with [], but that'll probably upset people, so I don't really
care if it is possible.

• Strictness of unquoted keys.

This is just legacy crap honestly, if we make up new syntax, we
shouldn't include the old mess in it. I think everyone is quoting
their strings by now..

• Support => in addition to : as a key:value separator.

Same as my point on [] above, I think adopting the JSON notation
should be done fully, keeping this stuff in might be ok to make people
happy, but it does not make much sense.

• possibility of simply not supporting the \u### syntax for Unicode characters in literal strings (just like the rest of PHP).

This is still PHP strings, they should behave as such. Sounds good to me.

• Should mixed-format (numeric and associative arrays) be allowed? (e.g. [1,'two':2, 3])

Assuming we keep [] to arrays and {} to hashes as I said above, I'd
say no. In the rare cases that it is useful you can still use array()
if you really feel this is necessary..

I'm sure many people will disagree with this, and I don't really mind
how it ends up syntactically speaking, but please really consider
dropping the stdClass part, that'd really suck :/

Cheers

--
Jordi Boggiano
@seldaek :: http://seld.be/

14 years ago by Chris Stockton — view source

unread

Hello,

Thanks for working on this.

Please read, and if you have a comment that is not already covered in the RFC, raise it here. I'm definitely open to discussion, but I would really love to keep this discussion civil.

TBH, I dropped half-way through the original topic, so I'm sorry if I
missed something, but why don't we just treat {"foo":"bar"} as an
array? json_decode() can do it, and it makes complete sense since PHP
arrays are hashes too. I don't see much benefit to having this create
an object by default, especially since even if you use that notation
to send data to a JSON API, json_encode'ing a hash will create an
object.

It's the only pain point I really have, that I can't use true
json-syntax without ending up with this messy pile of objects/arrays
mixed together. If we do this, IMO the hashes should not be able to be
defined with [], but that'll probably upset people, so I don't really
care if it is possible.

• Strictness of unquoted keys.

This is just legacy crap honestly, if we make up new syntax, we
shouldn't include the old mess in it. I think everyone is quoting
their strings by now..

• Support => in addition to : as a key:value separator.

Same as my point on [] above, I think adopting the JSON notation
should be done fully, keeping this stuff in might be ok to make people
happy, but it does not make much sense.

• possibility of simply not supporting the \u### syntax for Unicode characters in literal strings (just like the rest of PHP).

This is still PHP strings, they should behave as such. Sounds good to me.

• Should mixed-format (numeric and associative arrays) be allowed? (e.g. [1,'two':2, 3])

Assuming we keep [] to arrays and {} to hashes as I said above, I'd
say no. In the rare cases that it is useful you can still use array()
if you really feel this is necessary..

I'm sure many people will disagree with this, and I don't really mind
how it ends up syntactically speaking, but please really consider
dropping the stdClass part, that'd really suck :/

Cheers

I think there is a clear benefit to allow {} as well as [] being
StdClass and array respectively. However, I understand your point as
well as the point of others when they speak of the usefulness of
StdClass, really this tells me perhaps we should look at adding some
basic enhancements to StdClass (I.E. some methods for example), or
perhaps a new class for default object creation. At the very least
maybe a way to specify the "default" class.

14 years ago by dukeofgaming — view source

unread

I like the idea of supporting both "=>" and ":". Would this work?:

$foo = {
'bar' : function(){
echo 'baz';
}
};

$foo->bar();

And I'm guessing this shouldn't work:

$array = array('foo' : 'bar');

Regards,

David

On Sun, Jun 5, 2011 at 4:11 PM, Chris Stockton chrisstocktonaz@gmail.comwrote:

Hello,
Thanks for working on this.

Please read, and if you have a comment that is not already covered in
the RFC, raise it here. I'm definitely open to discussion, but I would
really love to keep this discussion civil.

TBH, I dropped half-way through the original topic, so I'm sorry if I
missed something, but why don't we just treat {"foo":"bar"} as an
array? json_decode() can do it, and it makes complete sense since PHP
arrays are hashes too. I don't see much benefit to having this create
an object by default, especially since even if you use that notation
to send data to a JSON API, json_encode'ing a hash will create an
object.

It's the only pain point I really have, that I can't use true
json-syntax without ending up with this messy pile of objects/arrays
mixed together. If we do this, IMO the hashes should not be able to be
defined with [], but that'll probably upset people, so I don't really
care if it is possible.
   • Strictness of unquoted keys.
This is just legacy crap honestly, if we make up new syntax, we
shouldn't include the old mess in it. I think everyone is quoting
their strings by now..
   • Support => in addition to : as a key:value separator.
Same as my point on [] above, I think adopting the JSON notation
should be done fully, keeping this stuff in might be ok to make people
happy, but it does not make much sense.
   • possibility of simply not supporting the \u### syntax for
Unicode characters in literal strings (just like the rest of PHP).
This is still PHP strings, they should behave as such. Sounds good to me.
   • Should mixed-format (numeric and associative arrays) be
allowed? (e.g. [1,'two':2, 3])

Assuming we keep [] to arrays and {} to hashes as I said above, I'd
say no. In the rare cases that it is useful you can still use array()
if you really feel this is necessary..

I'm sure many people will disagree with this, and I don't really mind
how it ends up syntactically speaking, but please really consider
dropping the stdClass part, that'd really suck :/

Cheers

I think there is a clear benefit to allow {} as well as [] being
StdClass and array respectively. However, I understand your point as
well as the point of others when they speak of the usefulness of
StdClass, really this tells me perhaps we should look at adding some
basic enhancements to StdClass (I.E. some methods for example), or
perhaps a new class for default object creation. At the very least
maybe a way to specify the "default" class.

14 years ago by Zeev Suraski — view source

unread

-----Original Message-----
From: dukeofgaming [mailto:dukeofgaming@gmail.com]
Sent: Monday, June 06, 2011 12:18 AM
To: Chris Stockton
Cc: Jordi Boggiano; Sean Coates; PHP internals
Subject: Re: [PHP-DEV] Object and Array Literals

I like the idea of supporting both "=>" and ":". Would this work?:

$foo = {
'bar' : function(){
echo 'baz';
}
};

$foo->bar();

I guess it's not yet too late to surpass Perl in the front of obscurity...

Zeev

14 years ago by Sean Coates — view source

unread

$foo = {
'bar' : function(){
echo 'baz';
}
};

$foo->bar();

I guess it's not yet too late to surpass Perl in the front of obscurity...

Since the stuff to the right of the assignment operator (: in this case) is valid PHP, I don't see why this wouldn't be allowed if we adopt the {} syntax. It's not much different from this, which is currently valid:

$foo = (object)array(
'bar' => function () {
echo 'baz';
}
};

S

14 years ago by Sean Coates — view source

unread

$foo = {
'bar' : function(){
echo 'baz';
}
};

$foo->bar();

I guess it's not yet too late to surpass Perl in the front of obscurity...

Since the stuff to the right of the assignment operator (: in this case) is valid PHP, I don't see why this wouldn't be allowed if we adopt the {} syntax. It's not much different from this, which is currently valid:

$foo = (object)array(
'bar' => function () {
echo 'baz';
}
};

Matthew pointed out to me (on IRC) that this actually doesn't work in current PHP (you can't call an object property as a closure without one of the proxy functions like call_user_function_array()). My mistake.

Note that this shouldn't affect the RFC, and this behaviour should be addressed as a separate issue if people think it should work (FWIW, I do obviously think this should work, but that's a separate thread, please).

S

14 years ago by Pierre Joye — view source

unread

hi Sean,

Please add the RFC header so we know what's the status.

Some comments:

$a = [1,2,'three'];

I liked the existing RFC
(https://wiki.php.net/rfc/shortsyntaxforarrays) so I indeed like it
here too.

$a = ['one': 1, 'two': 2, 'three': 'three'];

-1, did not like before, I still do not like it :) It will certainly
create some confusions and does not bring a lot of benefits. I'm not
sure how it will work either with a possible support of named
arguments. Last but not least, has anyone played with the parser to
implement it? Also the : syntax was not the preferred one either in
the short syntax RFC.

About the anonymous objects, the usage of stdclass is rare, at least
for the ones I met or use. I'm not sure about the interoperability
argument as conversions will still happen, so as someone else said, it
looks familiar but has in my opinion nothing to do with
interoperability. I'd to say a temporary -1.

Something that can change my mind is the ability to initialize an
object and its property using a similar syntax, but it sounds tricky
or not too useful (getter/setter a la c# sounds much useful for
example, if we need something in this area).

A last comment for the record here, this whole JSON-like syntax sounds
wrong to me from the beginning. JSON does not aim to be written or
read by human being. It is about exchanging data between two ends. I
don't think using it as a base for a syntax in a language is a good
thing to do.

Hello.

I've posted a RFC concerning Object and Array Literals on the wiki: https://wiki.php.net/rfc/objectarrayliterals

Please read, and if you have a comment that is not already covered in the RFC, raise it here. I'm definitely open to discussion, but I would really love to keep this discussion civil.

To get the ball rolling, here are a few points that I think we need to discuss:

• Strictness of unquoted keys.
• Support => in addition to : as a key:value separator.
• possibility of simply not supporting the \u### syntax for Unicode characters in literal strings (just like the rest of PHP).
• Should mixed-format (numeric and associative arrays) be allowed? (e.g. [1,'two':2, 3])

I beg you to keep name-calling, conclusion-jumping, and general hostility out of this thread. Thanks for your attention.

S

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

14 years ago by Sean Coates — view source

unread

Please add the RFC header so we know what's the status.

Thanks for catching this.

$a = ['one': 1, 'two': 2, 'three': 'three'];

has anyone played with the parser to
implement it?

I have not, personally. I feel like it would be a waste of time at this point, unless a logical problem can be identified.

Also the : syntax was not the preferred one either in
the short syntax RFC.

This RFC is a superset of the short array syntax RFC, in my opinion.

About the anonymous objects, the usage of stdclass is rare, at least
for the ones I met or use.

We use it a lot. This grep is from the root of the Gimme Bar code (my work project):

$ grep -ir 'StdClass' * | wc -l
229

A last comment for the record here, this whole JSON-like syntax sounds
wrong to me from the beginning. JSON does not aim to be written or
read by human being. It is about exchanging data between two ends. I
don't think using it as a base for a syntax in a language is a good
thing to do.

You've just stated that you don't use this sort of thing very often (which is fine, but users who don't use this very often are not my intended target audience for this RFC).

In my experience, users who DO interact with systems that speak JSON (or a JSON-like syntax) find this very useful, and have been wanting it for a long time. I have anecdotal evidence of this, but I could draw up something more concrete if that's what is required to get this to pass.

S

14 years ago by Marcel Esser — view source

unread

Please add the RFC header so we know what's the status.

Thanks for catching this.

$a = ['one': 1, 'two': 2, 'three': 'three'];

has anyone played with the parser to
implement it?

I have not, personally. I feel like it would be a waste of time at this point, unless a logical problem can be identified.

Also the : syntax was not the preferred one either in
the short syntax RFC.

This RFC is a superset of the short array syntax RFC, in my opinion.

About the anonymous objects, the usage of stdclass is rare, at least
for the ones I met or use.

We use it a lot. This grep is from the root of the Gimme Bar code (my work project):

$ grep -ir 'StdClass' * | wc -l
229

A last comment for the record here, this whole JSON-like syntax sounds
wrong to me from the beginning. JSON does not aim to be written or
read by human being. It is about exchanging data between two ends. I
don't think using it as a base for a syntax in a language is a good
thing to do.

You've just stated that you don't use this sort of thing very often (which is fine, but users who don't use this very often are not my intended target audience for this RFC).

In my experience, users who DO interact with systems that speak JSON (or a JSON-like syntax) find this very useful, and have been wanting it for a long time. I have anecdotal evidence of this, but I could draw up something more concrete if that's what is required to get this to pass.

S

While I would have been happy with the short array syntax proposed
earlier, I do have to say that Sean's points make a lot of sense to me
and I am strongly inclined to agree with him.

I can't really see any harm in this superset compared to the previous;
it seems to me like it would just make a lot of things handier.

M.

--
Marcel Esser
VP/Engineering, CROSCON
Washington, D.C. Office
@: marcel.esser@croscon.com

office.us +1 (202) 470-6090
mobile.us +1 (202) 250-1988
mobile.de +49 (0)176 391 226 23

14 years ago by Daniel Convissor — view source

unread

Hi:

I wasn't keen on earlier proposals for the [] array syntax. Sean, your
case is laid out in a clear manner and addresses my concerns. I like
this RFC.

* Strictness of unquoted keys.

Keys should be quoted. At the very least, unquoted keys should raise an
E_NOTICE.

* Support => in addition to : as a key:value separator.

I guess.

* possibility of simply not supporting the \u### syntax for Unicode
characters in literal strings (just like the rest of PHP).

It'd be nice to have, but not essential.

* Should mixed-format (numeric and associative arrays) be allowed?
(e.g. [1,'two':2, 3])

Yes, just like JSON (kind of) and PHP support.

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

14 years ago by Paul Dragoonis — view source

unread

On Sun, Jun 19, 2011 at 3:56 AM, Daniel Convissor
danielc@analysisandsolutions.com wrote:

Hi:

I wasn't keen on earlier proposals for the [] array syntax. Sean, your
case is laid out in a clear manner and addresses my concerns. I like
this RFC.

* Strictness of unquoted keys.

Keys should be quoted. At the very least, unquoted keys should raise an
E_NOTICE.

* Support => in addition to : as a key:value separator.

I guess.

* possibility of simply not supporting the \u### syntax for Unicode
characters in literal strings (just like the rest of PHP).

It'd be nice to have, but not essential.

* Should mixed-format (numeric and associative arrays) be allowed?
(e.g. [1,'two':2, 3])

Yes, just like JSON (kind of) and PHP support.

I +1 the JSON syntax for keys on objects and arrays. Specifically I
mean quoting the keys, this will remove ambiguity if it was supposed
to use a constant or whatnot. String quoted keys++

Thanks,

--Dan

--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409