Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52975
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.83.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:from:date:message-id:subject:to
         :cc:content-type;
        b=LlCTS/CXWZYPiU6f/hbM6JOhV8SqjlzBh5xUfPLPXzFHlMJyQFu/TLFnPVDwGOLfGA
         TWfbvYS7OcnRthI4K3UVu1K5okAJH+g/JM+yUf3VyHYqREWBHsdWN3ETCYMyQ2LUOb23
         j4/JMQSTM4i2ZQvEeueuNASgHamycuNx+XWZM=
MIME-Version: 1.0
In-Reply-To: <BANLkTi=-kP-4OsL39pDVGP4Omfx9RLOfRA@mail.gmail.com>
References: <084D2F1E-87E7-44CF-B8B6-47A250AD928D@seancoates.com>
 <BANLkTinckpPROJd2M1WoaFZdPYEN9N9u4g@mail.gmail.com> <BANLkTi=-kP-4OsL39pDVGP4Omfx9RLOfRA@mail.gmail.com>
Date: Sun, 5 Jun 2011 16:18:19 -0500
Message-ID: <BANLkTimN4kQ5UHrhWWBv2AHBMbkp3-W_mQ@mail.gmail.com>
To: Chris Stockton <chrisstocktonaz@gmail.com>
Cc: Jordi Boggiano <j.boggiano@seld.be>, Sean Coates <sean@seancoates.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636c92addd1a5b004a4fd87e9
Subject: Re: [PHP-DEV] Object and Array Literals
From: dukeofgaming@gmail.com (dukeofgaming)

--001636c92addd1a5b004a4fd87e9
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I like the idea of supporting both "=3D>" and ":". Would this work?:

  $foo =3D {
    'bar' : function(){
       echo 'baz';
    }
  };

  $foo->bar();

And I'm guessing this shouldn't work:

  $array =3D array('foo' : 'bar');

Regards,

David

On Sun, Jun 5, 2011 at 4:11 PM, Chris Stockton <chrisstocktonaz@gmail.com>w=
rote:

> 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
> 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.
> >
> >>        =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..
> >
> >>        =95 Support =3D> 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.
> >
> >>        =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 m=
e.
> >
> >>        =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.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

--001636c92addd1a5b004a4fd87e9--