Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:52737
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.210.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;
        b=CuH+AT7EFZXhJVFlq/cUE+LOh4SSefm1ZTl0PGsSfSHQtrYI2JZKRj/dkW/x9a+kAT
         lbsXZV0A+v6XHkpLkE0uP6Q+Yf0Z38j9cAN/M6TTO5ZlRiesG98Gk5tFTdkgS9+A/EMr
         gSiLtXs7V5Mw10cuGJ+jyqiHkMgvwtShao1SA=
MIME-Version: 1.0
In-Reply-To: <68339132.20110602001939@cypressintegrated.com>
References: <4DE5368A.6050603@moonspot.net>
	<BANLkTikKe8qWfjkEnANo9p5=8s=JdcHujw@mail.gmail.com>
	<BANLkTi=Y=P-O=ZRtUzjQ5i3anE=h9PF7Bg@mail.gmail.com>
	<BANLkTi=YrZbBkFubHx48K=YeEhHi9eXj2A@mail.gmail.com>
	<8BEEEE49-8DA3-4634-BF9C-120F7A15B613@roshambo.org>
	<BANLkTi=ETnz8g53WwOmL-uZCBWzokPMrZQ@mail.gmail.com>
	<BANLkTikrkRbEqOfZUFio__GCwnoTKf966g@mail.gmail.com>
	<BANLkTinWpCQRcrsn+o0w-M4ar58VVSBXNw@mail.gmail.com>
	<EB840916-64F2-44D0-AB3C-73679661CF73@justincarmony.com>
	<BANLkTinLCuHiKEAiGTQHfA4riHfXy4npkA@mail.gmail.com>
	<F2B65D81-CD84-45E3-B4BE-DB7E41CE3BEF@seancoates.com>
	<BANLkTimvNmStcZhh71D_5JvcLTA_Rm9tKg@mail.gmail.com>
	<BANLkTine0xzoP6w_EfFHXU_-KXu4Z=YHiQ@mail.gmail.com>
	<A633CF2D7C7BED41B41F1E64F25507B80602209F91@MAILR001.mail.lan>
	<68339132.20110602001939@cypressintegrated.com>
Date: Thu, 2 Jun 2011 09:57:56 +0200
Message-ID: <BANLkTin_vYph3Jz=FsTLVU+9bKfjisJn_Q@mail.gmail.com>
To: Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>
Cc: John Crenshaw <johncrenshaw@priacta.com>, PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001636e0ae0fb4c80604a4b5fe0d
Subject: Re: [PHP-DEV] RFC: Short syntax for Arrays (redux)
From: eloybote@gmail.com (Eloy Bote Falcon)

--001636e0ae0fb4c80604a4b5fe0d
Content-Type: text/plain; charset=ISO-8859-1

2011/6/2 Sanford Whiteman <swhitemanlistens-software@cypressintegrated.com>

> > I don't think anyone cares about JSON for the sake of being perfect
> > JSON, I didn't intend to give that impression.
>
> Then you should stop saying "pure JSON" and "true JSON" constantly!
>
> > I'm  only  hoping for something that generally works on par with all
> > the  other  JSON parsers in the world.
>
> OK,  that  trashes  your  example,  where values were set based on the
> result  of  a PHP function. There is no "par" for JSON parsers running
> methods  _at  creation  time_,  within  the  server  (author) context.
> Setting  vars  to  the return value of a function is something we take
> for  granted  in  real  languages,  but it cannot happen within what a
> knowledgeable person would call "JSON."
>
> > Yes,  JSON  is a very specific encoding, but when a developer writes
> > something  "jsony",  what  they  mean  is  "an object/array with the
> > following  structure/values",  because  that  is  what  the encoding
> > really represents.
>
> Not Javascript developers. Maybe jQiddies think that
>
>    {'$gt': strtotime('-1 day')}
>
> is "JSONy" more than it is "JS objecty"?
>
> This is like starting from "Wouldn't inline CSVs be great for creating
> arrays?"  and  drifting  to "I mean, not like with that comma-escaping
> stuff,  and,  uh, newlines would be allowed in the middle of a record,
> and  you'd  have to allow create-time interpolation of function calls.
> You know, CSVy!"
>
> Only  thing  I  might  generously  refer  to  as  being "JSONy," while
> provably  not being valid JSON, is a string that conforms in every way
> _except_  for  using  single  quotes  --  everywhere  that doubles are
> required  --  instead  of  using  doubles.  Anything else is someone's
> mangled "JankySON" or just not JSON.
>
> -- S.
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


 -1 to the RFC.
+1 to => against : if the array short syntax it's finally implemented.

I, being a lazy programmer, don't want anymore new syntax to do the same
thing. I don't care if it a) saves me houndred of kaystrokes in the
definition of arrays, or if b) it's more familiar with
_put_your_favorite_syntax_here_ because:

a) I prefer the simple way of _this_ is done _this_ way against _this_ is
done _this_ way or _this_another_ way or _this_yet_another_ way.
b) When another new fancy tendency of encoding appear I don't want to see it
in the core, because another one will appear in the future and then we will
be in the same point, stacking stuff forever or talking about deprecating
the old and breaking BC.

My point is: I'm for implementing something that can't be done currently in
PHP, but against for implementing another way of doing the same.

--001636e0ae0fb4c80604a4b5fe0d--