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.com>wrote:
> 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
>
>
