On 1 June 2011 12:41, Lester Caine wrote:
> At the current time I think that PHP would need to restructure how it is
> packaged up to provide a single repo in both HG or GIT. Keeping SVN ( I'd
> still prefer CVS here it works BETTER as a master for DVCS! ) as the master
> from which we CAN curren
Hi Lester,
AFAIK both mercurial and git support sub-repositories nicely now:
http://mercurial.selenic.com/wiki/Subrepository
http://www.kernel.org/pub/software/scm/git/docs/git-submodule.html
Regarding the graphical tools, I don't use them that much, but I see your
point. Personally, I just occa
Drak wrote:
At the current time I think that PHP would need to restructure how
it is packaged up to provide a single repo in both HG or GIT.
Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
for DVCS! ) as the master from which we CAN currently sync using HG
Hmm, I can edit pages within the RFC namespace but I cannot edit
https://wiki.php.net/rfc.
Regards,
David
On Wed, Jun 1, 2011 at 1:38 AM, dukeofgaming wrote:
> Thanks, I also don't think that was the case.
>
> Regards,
>
> David
>
>
> On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson wrote:
>
>>
>
On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine wrote:
> Drak wrote:
>
>>At the current time I think that PHP would need to restructure how
>>it is packaged up to provide a single repo in both HG or GIT.
>>Keeping SVN ( I'd still prefer CVS here it works BETTER as a master
>>for DVCS
+1 from me to *any* of the short-form suggestions (JSON or otherwise).
On 31 May 2011 19:42, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people
dukeofgaming wrote:
hggit + Mercurial Eclipse + Eclipse means I could not care less what
the target is EXCEPT that one can't write a project that is JUST the
set of sub-modules that you want to pull together. IDEALLY - both
GIT and HG would just pull stuff from which ever is provi
On Wed, Jun 1, 2011 at 3:24 AM, Lester Caine wrote:
> dukeofgaming wrote:
>
>>hggit + Mercurial Eclipse + Eclipse means I could not care less what
>>the target is EXCEPT that one can't write a project that is JUST the
>>set of sub-modules that you want to pull together. IDEALLY - both
2011/5/31 Brian Moon :
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with ca
On Tue, May 31, 2011 at 8:42 PM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
>
+1 for the current patch.
Tyrael
dukeofgaming wrote:
I know it will be a while until any choice of DVCS is adopted by PHP,
but I'll be creating an RFC as soon as I can edit the wiki (I can edit
the rfc namespace but cannot edit the rfc page itself to add the entry)
so that we can start making note of the current challenges and c
> -Original Message-
> From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
> Etienne Kneuss
> Sent: 01 June 2011 01:57
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Re: RFC: Short syntax for Arrays (redux)
>
> +1 for a short array syntax.
>
> But only if you keep it c
After that argument, I think I'm against ":" now too. +1 to "=>"
Could "{ }" be implemented for objects too then?.
Regards,
David
On Wed, Jun 1, 2011 at 4:36 AM, Ford, Mike wrote:
> > -Original Message-
> > From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
> > Etienne Kn
Big +1 on the patch. The ":" although a better choice would be
asymmetric to how its done inside array().
On Wed, Jun 1, 2011 at 11:50 AM, dukeofgaming wrote:
> After that argument, I think I'm against ":" now too. +1 to "=>"
>
> Could "{ }" be implemented for objects too then?.
>
> Regards,
>
>
Hi,
Long due but finally sending the final RFC for the release process.
There a couple of changes since the last time, they are all about
making it more transparent or catch the edge cases. We also got new
proposers on board, we are now basically almost all active devs on
board.
URL: https://wik
Using an explicit json_decode is actually a huge problem. It isn't just hard to
write encoded stuff into strings, it is a security issue because you have to
encode the values that you are then encoding into JSON. For example:
json_decode('{a: "a", b: "b", foo: "'.$_POST['foo'].'"}'); // !!! Secu
Hi,
In my opinion a restriction "API compatibility must be kept (internals
and userland)" for x.y.z to x.y+1.z is too strict. It just can block
some new features forever.
I would suggest to change "API compatibility must be kept" to "API
backward compatibility must be kept as much as possibl
hi,
On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov wrote:
> Hi,
>
> In my opinion a restriction "API compatibility must be kept (internals and
> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
> features forever.
btw, new APIs do not break API or API.
I do not think we
On Wed, Jun 1, 2011 at 1:12 PM, Pierre Joye wrote:
> hi,
>
> On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov wrote:
>> Hi,
>>
>> In my opinion a restriction "API compatibility must be kept (internals and
>> userland)" for x.y.z to x.y+1.z is too strict. It just can block some new
>> features foreve
That isn't measurable, so it is a suggestion, not a standard. It also creates
serious problems in userland if APIs change. API changes lead hosts to
literally take years to update to new versions of PHP, for fear of breaking the
sites that host with them. What about:
Userland API compatibility
On Wed, 1 Jun 2011, Internals wrote:
> URL: https://wiki.php.net/rfc/releaseprocess
Comments again-they are mostly similar as before-I was quite annoyed
that I didn't even get feedback on when I sent it last time:
> Example time line with two majors versions
> However it could happen
On Wed, 1 Jun 2011, Etienne Kneuss wrote:
> +1 for a short array syntax.
I'm still -1 on it. It makes absolutely unreadable code (yes, also in
JavaScript with f.e. MongoDB).
> But only if you keep it consistent, PHP has always been using => for
> key/val association, I don't see any reason to s
2011/5/31 Brian Moon :
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reverse his
> thoughts as well (with ca
> This variant is not workable, because there are (in the example) in 2014
> *five* branches. Merging between those, manually and automatically is
> going to be a major pain. I'd say we all rather want to focus our time
> on fixes and new features; and not spend more time doing branch merging,
> wh
On Wed, Jun 1, 2011 at 1:45 PM, Ilia Alshanetsky wrote:
>> This variant is not workable, because there are (in the example) in 2014
>> *five* branches. Merging between those, manually and automatically is
>> going to be a major pain. I'd say we all rather want to focus our time
>> on fixes and new
Holly crap, god save us from that.
+1 on short syntax (personally I try to avoid it in JS too - I use new
Array() or JSON), but no : please. It's just ridiculous for PHP.
2011/6/1 Patrick ALLAERT :
> 2011/5/31 Brian Moon :
>> https://wiki.php.net/rfc/shortsyntaxforarrays
>>
>> Since this was brou
Em Tue, 31 May 2011 19:42:18 +0100, Brian Moon
escreveu:
https://wiki.php.net/rfc/shortsyntaxforarrays
-1
I see very little benefit, specially in my keyboard layout, where typing [
and ] requires pressing Alt Gr + 8/9.
Plus, it can cause confusion because [] is currently used for arra
>> * running the various test suites (phpt, custom real life tests,
>> platform specific tests). Some tests need a day to run
>> * November, Final
>> * Last RC taken as final, golden release (no change between the last RC
>> and the final version)
>
> TBH, I think 6 months is too
My personal feel about this is that yes, short arrays are not bad, but
things like
$a = new A;
$a[array()];
just scare the crap of me when I see them. To me PHP is easy on syntax
and it's good. When I see Ruby or Python code with all it's crazy
magic I feel sick. Still one day I will have to lear
My kneejerk reaction to this, as no one particularly important, is to
not allow mixing those syntaxes.
I looked at the RFC a minute ago, and I read a reference to a parallel
solution to this being named parameters. Which, I think, is not
accurate. The problem with the array() notation is defin
Am 31.05.2011 20:42, schrieb Brian Moon:
> https://wiki.php.net/rfc/shortsyntaxforarrays
-1
--
Sebastian BergmannCo-Founder and Principal Consultant
http://sebastian-bergmann.de/ http://thePHP.cc/
--
PHP Internals - PHP Runtime Development Mailing
can we please (please!) focus on voting on the RFC and avoid an
enumeration of all possible syntax, formats, ideas, trolls&co we had
in the last decade? Simply vote and let us move one.
Thanks for your understanding,
On Wed, Jun 1, 2011 at 2:05 PM, Marcel Esser wrote:
> My kneejerk reaction to t
On 2011-05-31, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> PHP SVN account holder voters
>=
> Pro: Andrei Zmievski, Andi Gutmans, Pierre Joye, Rasmus Lerdorf,
> Stanislav Malyshev, Brian Moon, Kalle Sommer Nielsen, Edin Kadribasic
>
> Contra:
pls add your svn handle in the right section:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote
On Wed, Jun 1, 2011 at 2:08 PM, Sebastian Bergmann wrote:
> Am 31.05.2011 20:42, schrieb Brian Moon:
>> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> -1
>
> --
> Sebastian Bergmann
btwr, I did not mean to kill the discussions but it would be awesome
if every participant would read the past discussions about this RFC
and replies accordingly.
Yes, there are alternatives and other needs related to this RFC, but
it is really time to go with it or forget it.
Cheers,
On Wed, Jun
On Wed, Jun 1, 2011 at 6:04 AM, Gustavo Lopes wrote:
> On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm
> wrote:
>
>>> Agree with Derick, strictly speaking, in maths science, INF != INF.
>>
>> I disagree,based on quote from
>> http://compilers.iecc.com/comparch/article/98-07-134:
>>
>> "Since
On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
> > This variant is not workable, because there are (in the example) in 2014
> > *five* branches. Merging between those, manually and automatically is
> > going to be a major pain. I'd say we all rather want to focus our time
> > on fixes a
Sounds reasonable.
2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd s
On 06/01/2011 01:59 AM, Rasmus wrote:
Other than a couple of grumpy old-timers, I
think we are in agreement that we should add a short array syntax.
Well, thanks for calling me that! =)
But seriously, I don't think all of these people are grumpy old-timers:
Contra: Antony Dovgal, Derick Ret
On 05/31/2011 10:42 PM, Brian Moon wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
I can has vote on this RFC https://wiki.php.net/rfc/shortsyntaxforfunctions ?
--
Wbr,
Antony Dovgal
---
http://pinba.org - realtime statistics for PHP
--
PHP Internals - PHP Runtime Development Mailing Lis
hi,
2011/6/1 Johannes Schlüter :
> On Wed, 2011-06-01 at 13:45 +0200, Ilia Alshanetsky wrote:
>> > This variant is not workable, because there are (in the example) in 2014
>> > *five* branches. Merging between those, manually and automatically is
>> > going to be a major pain. I'd say we all rath
Pierre,
Doing a release could be simplified through automation as you've said.
However keeping synchronized patches across frequently incompatible
(non-identical) code bases is much less trivial and requires quite a
bit of work by anyone making the bug fixes. Having >3 branches for bug
fixes makes
2011/6/1 Ilia Alshanetsky :
> Pierre,
>
> Doing a release could be simplified through automation as you've said.
> However keeping synchronized patches across frequently incompatible
> (non-identical) code bases is much less trivial and requires quite a
> bit of work by anyone making the bug fixes.
+1
On Tue, May 31, 2011 at 1:42 PM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus (
> http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where several
> people including Andi chimed in on it and Ilia seemed to reve
Hi,
From a userland perspective, there should be absolutely no feature addition in
a "bugfix" version (x.y.Z+1) : we would see (just like what we see today)
frameworks, apps, or libraries depending on specific bugfix releases, and this
would not make php versioning easier to understand for any
This discussion seems to lack real-world examples…
Derick wrote:
> I'm still -1 on it. It makes absolutely unreadable code (yes, also in
> JavaScript with f.e. MongoDB).
Here's an actual snippet from my production code (which interfaces with
ElasticSearch):
http://paste.roguecoders.com/p/0747f
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates wrote:
> This discussion seems to lack real-world examples…
>
> Derick wrote:
>> I'm still -1 on it. It makes absolutely unreadable code (yes, also in
>> JavaScript with f.e. MongoDB).
>
>
> Here's an actual snippet from my production code (which interfa
On Jun 1, 2011, at 7:30 AM, Ilia Alshanetsky wrote:
> On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates wrote:
>> This discussion seems to lack real-world examples…
>>
>> Derick wrote:
>>> I'm still -1 on it. It makes absolutely unreadable code (yes, also in
>>> JavaScript with f.e. MongoDB).
>>
>>
In all seriousness, there is a vast majority of PHP developers who are not
represented on this list. I was surprised to see someone mentioning for calling
for another vote so soon after this discussion came up. Perhaps instead of
debating on readability and usefulness, we actually do some resear
You probably need to reset your password.
I had the same issue previously.
On Wed, Jun 1, 2011 at 4:50 AM, dukeofgaming wrote:
> Hmm, I can edit pages within the RFC namespace but I cannot edit
> https://wiki.php.net/rfc.
>
> Regards,
>
> David
>
> On Wed, Jun 1, 2011 at 1:38 AM, dukeofgaming wr
On 06/01/2011 08:00 AM, Justin Carmony wrote:
> In all seriousness, there is a vast majority of PHP developers who are not
> represented on this list. I was surprised to see someone mentioning for
> calling for another vote so soon after this discussion came up. Perhaps
> instead of debating on
Would it be possible to have a vote on the various options being proposed here?
I think JSON syntax is definitely more concise and easier to type, as well as
more convenient -- but I don't think it makes sense for PHP without changing
how arrays work (I'm all for that, but that's a different dis
>> Here's an actual snippet from my production code (which interfaces with
>> ElasticSearch):
>> http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html
>>
>> If you consider this readable, you're fare more literate than I will ever be
>> (-:
>
> Using JSON syntax would only "maybe"
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
However such API breaks where invisible for user-land and most
extensions, they required a lot of changes in O+, APC, xdebug, etc.
But, in case
Hi!
Before now each major (5.y+1) release introduced API changes.
We just couldn't introduce literal tables, interned strings, etc without
API changes.
I think by API there it means PHP-level API, i.e. one exposed to the
user, not binary API exposed to the extensions, which is meant by ABI.
There's something between the user level API and the ABI - which is source
level compatibility.
What Dmitry's pointing out that if we commit to source level compatibility,
it'll be quite limiting (based on past experience). If we don't commit to
source-level compatibility then we're fine. I g
Hi!
There's something between the user level API and the ABI - which is source
level compatibility.
That's a good point. We'd like to keep source-level incompatibilities to
a minimum - especially for simple extensions, not like APC :) - but I
agree it may be hard to maintain at 100% if we d
On Wed, Jun 1, 2011 at 6:47 PM, Dmitry Stogov wrote:
> Before now each major (5.y+1) release introduced API changes.
> We just couldn't introduce literal tables, interned strings, etc without API
> changes.
>
> However such API breaks where invisible for user-land and most extensions,
> they requi
Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote
On Tue, May 31, 2011 at 8:42 PM, Brian Moon wrote:
> https://wiki.php.net/rfc/shortsyntaxforarrays
>
> Since this was brought again recently by Rasmus
> (http://markmail.org/message/fx3brcm4ekh645se) and on Twit
Hello,
On Wed, Jun 1, 2011 at 10:19 AM, Pierre Joye wrote:
> Reminder: Pls add your votes here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>
May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.
--
PHP Internals - PHP Runtime Development Mai
Chris Stockton wrote:
Reminder: Pls add your votes here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>
May I please have wiki rights restored to my user "cstockton" if
possible, I would like to vote.
It would seem some people have not been watching the news?
http://www.php.net/ top n
Hi Lester,
On Wed, Jun 1, 2011 at 11:19 AM, Lester Caine wrote:
> Chris Stockton wrote:
>>>
>>> Reminder: Pls add your votes here:
>>> > https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>>> >
>>
>> May I please have wiki rights restored to my user "cstockton" if
>> possible, I would like to vo
On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye wrote:
> Reminder: Pls add your votes here:
> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
Who is allowed to vote?, are userland votes still going to count?, if so,
how does one qualify as userland voter?.
Best regards,
David Vega
I think the one that is active can be a voter.
Or maybe the ones that have any karma on php environment is considered a voter.
Cheers,
On Wed, Jun 1, 2011 at 4:21 PM, dukeofgaming wrote:
> On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye wrote:
>
>> Reminder: Pls add your votes here:
>> https://wik
>>> Reminder: Pls add your votes here:
>>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
>>
>>
>> Who is allowed to vote?, are userland votes still going to count?, if so,
>> how does one qualify as userland voter?.
>
> I think the one that is active can be a voter.
> Or maybe the ones tha
On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson wrote:
> I'm choosing to ignore this voting mechanism because it feels wrong.
We always voted based on php.net accounts (@php.net that is), whether
it is a good thing or not is another question and unrelated to this
RFC (for one, I consider that non
On Wed, Jun 1, 2011 at 2:38 PM, Philip Olson wrote:
> >>> Reminder: Pls add your votes here:
> >>> https://wiki.php.net/rfc/shortsyntaxforarrays/vote
> >>
> >>
> >> Who is allowed to vote?, are userland votes still going to count?, if
> so,
> >> how does one qualify as userland voter?.
>
> >
> >
On Wed, Jun 1, 2011 at 9:43 PM, dukeofgaming wrote:
> Yup, it feels rushed. The RFC should be cleaned up and I think this are the
> main items:
> - Ditch ":"
> - Ditch the JSON topic or open a separate RFC with it
> - Introduce the "{ }" syntax for objects and change the title
Both json and obje
>
>
> > David
>
> David who? :)
>
>
David Vega
On Jun 1, 2011, at 12:43 PM, Pierre Joye wrote:
> On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson wrote:
>
>> I'm choosing to ignore this voting mechanism because it feels wrong.
>
>
> We always voted based on php.net accounts (@php.net that is), whether
> it is a good thing or not is another qu
On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye wrote:
> I modified the vote page, pls move your votes to the desired syntax
> (or global -1)
This is a good idea to group things like this.
Back on the soapbox. All of this is just to reduce typing "array" (5
characters) before things?
Old:
$foo = a
To address the soapbox:
Its not just to reduce the five characters at the beginning, but when you have
more complex structures as well. There was already a great example shown
(http://paste.roguecoders.com/p/0747f2363c228a09e0ddd6f8ec52f2e8.html) of that.
Also, if object support is added (which
Personally, I think focusing on a character savings is the wrong
reason to take on any problem. I don't care how long it takes for me
to type code. I don't care how much extra hdd space it takes. But
what I do care about is how readable it is.
To me, the array shortcut syntax is pointless. Do
Hello,
On Wed, Jun 1, 2011 at 1:37 PM, Michael Shadle wrote:
> On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye wrote:
>
> 5 character difference for each array being saved. That's it. At the
> expense of syntax highlighters, IDEs, books, all becoming outdated and
> need to be updated. For a language
Hello,
On Wed, Jun 1, 2011 at 2:17 PM, Anthony Ferrara wrote:
> Personally, I think focusing on a character savings is the wrong
> reason to take on any problem. I don't care how long it takes for me
> to type code. I don't care how much extra hdd space it takes. But
> what I do care about is
First, why not go the opposite way and standardize the syntax - why
not make object() or Object() work like array() or Array()?
$person = object('name' => 'Justin',
'city' => 'ogden',
'state' => 'ut',
'country' => 'usa',
'favoriteNumbers' => array(4, 12, 37, 42),
'unluckyNumber
Spot on. It has nothing to do with extra typing (and that sort of design is
part of what ruined Ruby). My fingers move plenty fast and if extra characters
make things more safe or more readable, I'll be the first to sign up. In this
case, however, the extra characters just make things messy.
1.
> Now, the only reason I would personally support the array shortcut is
> if it was an implementation of JSON. I know that's not on the table
> here
I don't think anything is officially off the table, unless we forego discussion.
My application is largely JSON-powered. We pass data from back- to
For small linear arrays, neither format is "more readable" but for even mildly
complex structures, there is a clear difference. Consider the following Mongo
query:
$query = array(
'time'=>array('$and'=>array(
array('$gt'=>strtotime('-1 day')),
array('$lt'=>time()),
)),
> However, what you refer to is about internals API. We can (and did a
> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
> (read: signatures, source compatibility) if possible.
I think we need to clear it up in the RFC. My take:
- Switch from talking about 'ABI' to 'ext
On Wed, Jun 1, 2011 at 11:59 PM, John Crenshaw wrote:
> Spot on. It has nothing to do with extra typing (and that sort of design is
> part of what ruined Ruby). My fingers move plenty fast and if extra
> characters make things more safe or more readable, I'll be the first to sign
> up. In this
I've been giving it some more thought, and really, the more I think about
it, the more I am with Sean on the idea of having first-class JSON
support. It really just makes sense. PHP is a web-oriented language, and
we will all use it at some point. It's also very concise, and it's really
easy to lea
On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates wrote:
> This is not about saving five characters every time I type array(), it's
> about making my systems all work together in a way that's a little less
> abstracted, and a lot less prone to error.
Why not make your data in JSON and then $foo = js
Parsing together strings that mix single and double quotes, variables,
defined constants and etc, makes the problem significantly worse, not
better. So, json_encode is not a solution at all.
It's also not about PHP vs Node in any way; it's about interacting with
APIs that make heavy use of JSON or
> Why not make your data in JSON and then $foo = json_encode($data) ?
For exactly the same reason people actually use callbacks efficiently, now that
they don't have to create_function() them.
S
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
On Thu, Jun 2, 2011 at 12:10 AM, Zeev Suraski wrote:
>> However, what you refer to is about internals API. We can (and did a
>> lot) break ABI between x.y and x.y+1 and should really avoid breaking API
>> (read: signatures, source compatibility) if possible.
>
> I think we need to clear it up in t
> Vs. the JSON form:
> {
> time: {'$and': [
> {'$gt': strtotime('-1 day')},
> {'$lt': time()},
> ]},
> '$or': [
> {foo: 'bar'},
> {hello: 'world'}
> ]
> }
That isn't valid JSON for many different reasons... if you think
that's "pure JSON," you
I'm suddenly realizing that the actual need is, in many cases, specific to the
development circumstances. When developing heavily against/with other systems
that use JSON (like MongoDB, jQuery, various APIs, etc.) the value of true JSON
is immeasurable, and anything that isn't JSON would look wr
On Thu, Jun 2, 2011 at 12:22 AM, Marcel Esser wrote:
> It's also not about PHP vs Node in any way; it's about interacting with
> APIs that make heavy use of JSON or JSON-superset notations.
PHP supports json since years, http://www.php.net/json_decode /
encode, as well as many other serializatio
On 06/01/2011 03:09 AM, Pierre Joye wrote:
URL: https://wiki.php.net/rfc/releaseprocess
Pierre,
There are some immediately practical things here. Some things will
be a large jolt for the community and might be better introduced in
future releases.
Chris
Good:
- Scheduled releases
- U
On Wed, 1 Jun 2011 10:27:36 -0400, Sean Coates wrote:
This discussion seems to lack real-world examples…
Derick wrote:
I'm still -1 on it. It makes absolutely unreadable code (yes, also
in
JavaScript with f.e. MongoDB).
Here's an actual snippet from my production code (which interfaces
wit
hi Chris
On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
wrote:
>
>
> On 06/01/2011 03:09 AM, Pierre Joye wrote:
>
>> URL: https://wiki.php.net/rfc/releaseprocess
>
> Pierre,
>
> There are some immediately practical things here. Some things will
> be a large jolt for the community and might b
Just because the MongoDB developers were stupid enough to build a query
language on top of JSON does not mean that JSON or JavaScript object literals
need to be supported in PHP. And it wouldn't be possible anyway since JSON
allows Unicode escape sequences, and PHP cannot even represent those as
I still don't get it, the idea of making it look like json wont make it
json, it will be PHP, and if you dare to write you "jsony" object/array with
single quoted strings wont break the code even when its not JSON.
I'll say it again: not even Javascript supports 100% valid JSON. I'll say it
even m
hi David,
On Thu, Jun 2, 2011 at 12:47 AM, David Zülke
wrote:
> Just because the MongoDB developers were stupid enough to build a query
> language on top of JSON
Many of us know that you have a deep and constant hate for MongoDB.
However please do respect the netiquette and every developers her
Hrm. It seems to me that it's not just Mongo that has chosen that as a
query definition language. A fair number of other projects have, too. If
not as a query language, then related things.
As for decoding Unicode, well, json_decode seems to do a pretty good job.
And if I am not mistaken, they are
I don't think anyone cares about JSON for the sake of being perfect JSON, I
didn't intend to give that impression. I'm only hoping for something that
generally works on par with all the other JSON parsers in the world. In other
words something with roughly the same syntax, constraints, and flexi
The issue I have with that is that, regardless of the syntax chosen, even if it
meant a 100% inline JSON syntax, you would still (for obvious reasons) need to
parse any JSON string into PHP structures. You still have to do
json_load($php_or_json_string) or (god have mercy) eval($string). At that
On 02.06.2011, at 00:53, Marcel Esser wrote:
> Hrm. It seems to me that it's not just Mongo that has chosen that as a
> query definition language. A fair number of other projects have, too. If
> not as a query language, then related things.
It's the worst idea of this decade, and just because oth
> 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
1 - 100 of 101 matches
Mail list logo
