Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52971
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=IG13hHvBzr8MS22Btgu6qR7eMhylei3RQMkNFzuPO/xcGP4hY74G/b5dbt4rINgeTY
         7IIGmyeEnFwOasRCZs7vd0Qpz+pcfso/4cGjhDNCo0XUfsVH44e5A0pxX/pbsLchweDs
         pwX3qLfQ3CYq0U4IH8JKaXTwsjawc4EE76xEg=
MIME-Version: 1.0
In-Reply-To: <BANLkTinckpPROJd2M1WoaFZdPYEN9N9u4g@mail.gmail.com>
References: <084D2F1E-87E7-44CF-B8B6-47A250AD928D@seancoates.com>
	<BANLkTinckpPROJd2M1WoaFZdPYEN9N9u4g@mail.gmail.com>
Date: Sun, 5 Jun 2011 14:11:46 -0700
Message-ID: <BANLkTi=-kP-4OsL39pDVGP4Omfx9RLOfRA@mail.gmail.com>
To: Jordi Boggiano <j.boggiano@seld.be>
Cc: Sean Coates <sean@seancoates.com>, PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] Object and Array Literals
From: chrisstocktonaz@gmail.com (Chris Stockton)

Hello,

On Sun, Jun 5, 2011 at 2:03 PM, Jordi Boggiano <j.boggiano@seld.be> wrote:
> Thanks for working on this.
>
> On Sun, Jun 5, 2011 at 3:30 AM, Sean Coates <sean@seancoates.com> wrote:
>> Please read, and if you have a comment that is not already covered in th=
e 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.
>
>> =A0 =A0 =A0 =A0=95 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..
>
>> =A0 =A0 =A0 =A0=95 Support =3D> in addition to : as a key:value separato=
r.
>
> 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.
>
>> =A0 =A0 =A0 =A0=95 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.
>
>> =A0 =A0 =A0 =A0=95 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.