Re: [PHP-DEV] Object and Array Literals
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Sun, Jun 19, 2011 at 3:56 AM, Daniel Convissor dani...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
re JSON
· will never validate as JSON
·recognizablyviolates JSON quoting rules
· recognizably violates the JSON security concept…
…
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.
I have actually been excited about the discussion of this feature area
and anticipate my eventual +1 if JSON could be removed from the RFC.
Even though the term doesn't affect the way the feature works, by
upvoting the RFC one is approving of wording that may make it to the
general public, and I think this would be bad for PHP.
I was careful in the RFC to indicate that this is *not* JSON, but if others
feel as strongly as you do about the use of this term, I think it can be
removed without hurting the idea (as you indicated).
You're right that the RFC does not declare a syntax that will always validate
as JSON, nor does it respect serialization rules, but I see it more as a
declaration syntax than a serialization format, as it is proposed. The real
goal is to improve interaction with third parties, which I think the proposed
syntax would allow.
That said, other than the \u syntax, I believe that the proposed declaration
syntax would still allow JSON from a third party to me interpreted by PHP, in a
way that makes sense in PHP.
Somewhat on a side note, I do not understand the statement that
using a strict syntax would not conform with the PHP way
or at least how it relates to this RFC.
This is directly related to the JSON-non-strictness that everyone seems to want
(me included). For example the following is completely invalid in JSON, but
normally OK (for small values of OK) in PHP:
(not-)JSON: {foo: 1}
(not-)JSON: {'foo': 1}
PHP: array(foo = 1)
PHP: array('foo' = 1)
(For anyone who doesn't follow, correct way in JSON is to use not '.)
Thanks for the comments.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
a) JSON is actually being mentioned to advocate for the syntax with for the
sake of *familiarity*.
b) Interoperability is being confused with familiarity.
My goal is interoperability. Familiarity is a factor, definitely.
c) Actual interoperability of the syntax with JSON is just a happy
coincidence (same as with Ruby)
I disagree; see below.
d) In no context this notation could function as JSON and PHP at the same
time, mainly because PHP requires tags
I don't think they could be interchangeable, programmatically, as files, but
copying and pasting from PHP to curl for ElasticSearch would have saved me
hours of back-and-forth over the past months.
e) There is a strong resistance to change, I bet the detractors of this
short syntax (even with the :) would change their opinion after using it,
just the way some of us used to hate the idea of namespaces with \ and
after using it changed our opinion (specially with the autoloading standard
that actually reflects file structure, e.g. in Symfony2).
Absolutely agree. In addition, for me to see the value in this, it took more
than just knowing how it worked, but immersing myself in this syntax (really
wanting it).
When short array syntax was first proposed, I didn't care. As I've said here a
couple times, this is not about saving 5 characters by changing array( into
[, but about many other things.
f) If JSON ceased to exist in this very moment, supporters of the syntax
would be still supporting it and perhaps detractors would accept it.
The effect of mentioning JSON, and implying direct compatibility with JSON
technologies and JSON itself is just adding FUD.
I don't want blanket compatibility. I do want to be able to write PHP that
*CAN* be passed off to third-parties verbatim, if care is taken to do so. Most
of the time I use JSON, this care is not required, though. I don't think it's
FUD, but I do see your point in that the term JSON is strangely offensive to
some, and I would be willing to remove it (but not if only you two think this
way).
+1 to removing references to JSON from the RFC, because [ ], { } and :
make enough sense by themselves.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Mon, Jun 6, 2011 at 8:48 AM, Sean Coates s...@seancoates.com wrote:
I was careful in the RFC to indicate that this is *not* JSON, but if others
feel as strongly as you do about the use of this term, I think it can be
removed without hurting the idea (as you indicated).
Still, it is mentioned so many times that it could be unintentionally
misleading IMHO.
You're right that the RFC does not declare a syntax that will always
validate as JSON, nor does it respect serialization rules, but I see it more
as a declaration syntax than a serialization format, as it is proposed. The
real goal is to improve interaction with third parties, which I think the
proposed syntax would allow.
That said, other than the \u syntax, I believe that the proposed
declaration syntax would still allow JSON from a third party to me
interpreted by PHP, in a way that makes sense in PHP.
Can you provide an use case and code example of how that would look?
Somewhat on a side note, I do not understand the statement that
using a strict syntax would not conform with the PHP way
or at least how it relates to this RFC.
This is directly related to the JSON-non-strictness that everyone seems to
want (me included). For example the following is completely invalid in JSON,
but normally OK (for small values of OK) in PHP:
(not-)JSON: {foo: 1}
(not-)JSON: {'foo': 1}
PHP: array(foo = 1)
PHP: array('foo' = 1)
(For anyone who doesn't follow, correct way in JSON is to use not '.)
Thanks for the comments.
As mentioned earlier, I think the resemblance to JSON is just a happy
coincidence, the syntax makes enough sense by itself. You can argument that
its familiarity/friendliness/ubiquity makes it a good option, but in its
current state (i.e. not defining why JSON compatibility is justified) I'd
say it is not complete.
Regards,
David
Re: [PHP-DEV] Object and Array Literals
Can you provide an use case and code example of how that would look?
Sure.
Here's how an ElasticSearch query currently looks in PHP:
$esQuery = new \StdClass;
$esQuery-query = new \StdClass;
$esQuery-query-term = new \StdClass;
$esQuery-query-term-name = 'beer';
$esQuery-size = 1;
// OR
$esQuery = (object)array(
query = (object)array(
term = (object)array(
name = beer
)
),
size = 1
);
…and here's how it could look with the proposed syntax:
?php
$esQuery = {
query : {
term : {
name: beer
}
},
size : 1
};
…and here's how I'd use curl to ensure that the query I'm issuing does in fact
work with ElasticSearch:
$ curl http://localhost:9200/gimmebar/assets/_search?pretty=1 -d'{
query : {
term : {
name: beer
}
},
size : 1
}'
Even considering the `(object)array(` syntax, it's much easier to work with an
external query (as shown with curl), if we have a (nearly) JSON-compatible
syntax in PHP.
Note that I *could* have written the PHP definition of $esQuery with the
proposed syntax and non-JSON compatible syntax (single quotes, for example),
but I chose to write it with double quotes because I knew I might also want to
pass it to curl.
Realistically, beer would be in a variable (maybe `{term: {name:
$term}}`), but replacing just the variables is certainly much easier than
translating the `new \StdClass` syntax.
The argument for right-hand-side assignments being allowed in the proposed
syntax (such as in `{'time': time()}`) is still valid because I expect this
syntax will be used both for interoperating with third party services (as
above), but also generally for object and array creation without a care about
third parties.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
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. On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Mon, 2011-06-06 at 13:10 -0400, Sean Coates wrote: 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.es...@croscon.com office.us +1 (202) 470-6090 mobile.us +1 (202) 250-1988 mobile.de +49 (0)176 391 226 23 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
$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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
Hello,
On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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();
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 chrisstockto...@gmail.comwrote:
Hello,
On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano j.boggi...@seld.be wrote:
Thanks for working on this.
On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates s...@seancoates.com wrote:
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.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Object and Array Literals
-Original Message-
From: dukeofgaming [mailto:dukeofgam...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
$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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
As ordered, I will stick to what I feel are community issues and try to be impersonal. If PHP users want to be clear that we have made an educated choice to use/maintain the language, we should appear impeccably well-versed in the technologies which complement and compete with PHP. I feel strongly that one should use the best-fit terminology when referring to outside technologies whenever possible, avoiding poorer-fit misnomers. In the case of syntax that -- · will never validate as JSON -- a syntax which is the subject of a well-trafficked IETF RFC; has no standardized non-strict/quirks/ compatibility mode that would suggest that the term can have multiple meanings; and has no understood history of multiple meanings by experts in its use; ·recognizablyviolates JSON quoting rules, not as a secondary/optional syntax, but in the primary examples given in the RFC; and · recognizably violates the JSON security concept that excludes assignment and invocation [RFC 4627] when using host variables or function invocations on LHS or RHS -- yet -- · is recognizably similar to JavaScript object literal syntax, especially wrt quotation marks, with the notable exception of allowing interpolation/invocation on LHS; · thanks to recent major moves in server-side JS (nodeJS), does not need a poor-fit comparison to an interchange/serialization format in order to be understood, but can be recognized as JS-like by server-side folks; · allows PHP string interpolation within RHS, which is not in direct conflict with JS object literal syntax -- as JS simply doesn't support interpolation that would have to be allowed/denied in this context -- but which is in direct conflict with the JSON standard, which _conceptually_ denies such dereferencing; and · insofar as it does directly conflict with JS object literal rules in allowing the LHS (key) of a key:value pair to contain variables or function invocations, still _does not_ add or allow anything that is allowed in JSON, as JSON is more restrictive than JS object literals and prohibits all these syntaxes _and more_ -- I do not feel that the acronym JSON has any clarifying nor edifying place in the RFC describing this syntax. Rather, I would suggest one of the following: · JavaScript-like [object|array] literal syntax · bare-bracket [object|array] literal syntax · short [object|array] literal syntax · compact [object|array] ... · quick [object|array] ... · colon-pair [object|array] ... I have actually been excited about the discussion of this feature area and anticipate my eventual +1 if JSON could be removed from the RFC. Even though the term doesn't affect the way the feature works, by upvoting the RFC one is approving of wording that may make it to the general public, and I think this would be bad for PHP. It might also be noted (h/t David Vega) that Ruby adopted a syntax similar to that proposed here and completely avoided using the term JSON in final documentation, as I hope will be done with PHP even if this RFC continues to use the term. Somewhat on a side note, I do not understand the statement that using a strict syntax would not conform with the PHP way or at least how it relates to this RFC. It is my understanding that, while concepts including (but not limited to) type-juggling, dynamic typing, and use of undeclared vars are emblematic of the PHP way, what I would call strict syntax[es] are encouraged in many areas (without E_STRICT). For one example, missing semicolons may be fatal in PHP while symmetrical syntax works in JS. For another one off the top, PHP's XML modules require well-formedness by default, not what I would expect if there were such a thoroughgoing loose approach to syntax. -- S. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Object and Array Literals
On Sun, Jun 5, 2011 at 6:06 PM, Sanford Whiteman
sa...@cypressintegrated.com wrote:
-- I do not feel that the acronym JSON has any clarifying nor edifying
place in the RFC describing this syntax.
Rather, I would suggest one of the following:
· JavaScript-like [object|array] literal syntax
· bare-bracket [object|array] literal syntax
· short [object|array] literal syntax
· compact [object|array] ...
· quick [object|array] ...
· colon-pair [object|array] ...
I have actually been excited about the discussion of this feature area
and anticipate my eventual +1 if JSON could be removed from the RFC.
Even though the term doesn't affect the way the feature works, by
upvoting the RFC one is approving of wording that may make it to the
general public, and I think this would be bad for PHP.
It might also be noted (h/t David Vega) that Ruby adopted a syntax
similar to that proposed here and completely avoided using the term
JSON in final documentation, as I hope will be done with PHP even if
this RFC continues to use the term.
Bravo for ponting that out, your argument has cleared my mind a little while
trying to understand this side (I'm actually against the JSON
interoperability argument [because it does not make sense to me], but not
the syntax).
After reading this new RFC and pondering about the JSONy implications, the
multi-part conclusion that I reached is that:
a) JSON is actually being mentioned to advocate for the syntax with for the
sake of *familiarity*.
b) Interoperability is being confused with familiarity.
c) Actual interoperability of the syntax with JSON is just a happy
coincidence (same as with Ruby)
d) In no context this notation could function as JSON and PHP at the same
time, mainly because PHP requires tags
e) There is a strong resistance to change, I bet the detractors of this
short syntax (even with the :) would change their opinion after using it,
just the way some of us used to hate the idea of namespaces with \ and
after using it changed our opinion (specially with the autoloading standard
that actually reflects file structure, e.g. in Symfony2).
f) If JSON ceased to exist in this very moment, supporters of the syntax
would be still supporting it and perhaps detractors would accept it.
The effect of mentioning JSON, and implying direct compatibility with JSON
technologies and JSON itself is just adding FUD.
+1 to removing references to JSON from the RFC, because [ ], { } and :
make enough sense by themselves.
Regards,
David Vega
[PHP-DEV] Object and Array Literals
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
