# Object and Array Literals - Thread: https://externals.io/message/52909 - Original archive: https://news-web.php.net/php.internals/52909 - Started by Sean Coates on 2011-06-05T01:30:49+00:00 - Messages: 12 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #52909 — Sean Coates — 2011-06-05T01:30:49+00:00 URL: https://externals.io/message/52909#52909 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 --- ## #52970 — Jordi Boggiano — 2011-06-05T21:03:50+00:00 URL: https://externals.io/message/52909#52970 · In reply to: #52909 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/ --- ## #52971 — Chris Stockton — 2011-06-05T21:11:46+00:00 URL: https://externals.io/message/52909#52971 · In reply to: #52970 Hello, > Thanks for working on this. > > > > […] > > 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. > > > […] > > 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.. > > > […] > > 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. > > > […] > > This is still PHP strings, they should behave as such. Sounds good to me. > > > […] > > 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. --- ## #52975 — dukeofgaming — 2011-06-05T21:18:19+00:00 URL: https://externals.io/message/52909#52975 · In reply to: #52971 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 wrote: > Hello, > > > > […] > the RFC, raise it here. I'm definitely open to discussion, but I would > really love to keep this discussion civil. > > […] > Unicode characters in literal strings (just like the rest of PHP). > > […] > allowed? (e.g. [1,'two':2, 3]) > > […] > > 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. --- ## #52976 — Zeev Suraski — 2011-06-05T21:21:41+00:00 URL: https://externals.io/message/52909#52976 · In reply to: #52975 > -----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 --- ## #52978 — Sean Coates — 2011-06-05T21:47:28+00:00 URL: https://externals.io/message/52909#52978 · In reply to: #52976 > > […] > > 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 --- ## #53047 — Pierre Joye — 2011-06-06T16:44:04+00:00 URL: https://externals.io/message/52909#53047 · In reply to: #52909 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 --- ## #53055 — Sean Coates — 2011-06-06T17:10:04+00:00 URL: https://externals.io/message/52909#53055 · In reply to: #53047 > Please add the RFC header so we know what's the status. Thanks for catching this. > > […] > > 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 --- ## #53058 — Marcel Esser — 2011-06-06T17:18:07+00:00 URL: https://externals.io/message/52909#53058 · In reply to: #53055 > > […] > > Thanks for catching this. > > > […] > > I have not, personally. I feel like it would be a waste of time at this point, unless a logical problem can be identified. > > > […] > > This RFC is a superset of the short array syntax RFC, in my opinion. > > > […] > > 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 > > > […] > > 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 --- ## #53075 — Sean Coates — 2011-06-06T19:54:24+00:00 URL: https://externals.io/message/52909#53075 · In reply to: #52978 > > […] > > 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 --- ## #53370 — Daniel Convissor — 2011-06-19T02:56:55+00:00 URL: https://externals.io/message/52909#53370 · In reply to: #52909 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 --- ## #53371 — Paul Dragoonis — 2011-06-19T03:05:21+00:00 URL: https://externals.io/message/52909#53371 · In reply to: #53370 On Sun, Jun 19, 2011 at 3:56 AM, Daniel Convissor 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. > > > > […] > > Keys should be quoted.  At the very least, unquoted keys should raise an > E_NOTICE. > > > > […] > > I guess. > > > > […] > > It'd be nice to have, but not essential. > > > > […] > > 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