Hi!
If a handful of experienced people decided to go forward with my
crackpot idea above, would you be in support, just because they are?
No, but I wouldn't say that nobody needs it. I'd say it's a bad idea
despite somebody needing it, for reasons so and so.
I figured it was tough, based
Hi,
I remember having wiki editing privileges not so long ago, I was going to
enter and add the entry for discussions at
https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
Would it be too much to ask to have them enabled?.
Best regards,
David Vega
Hi,
I thought it might be interesting for all to read some feedback I got from
some questions I made to the Joomla community, specifically, the guys and
gals that have been implementing the decoupling of the Joomla framework: the
Joomla Platform.
They currently still use svn officially but they
Michael Maclean wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
snip
I'm all for this, though I would confess to having a preference for the
second syntax:
$arr = [ 'foo' = 'bar', 'baz' = 'foo' ]
seems to fit better with PHP than the
On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
Hi,
I remember having wiki editing privileges not so long ago, I was going to
enter and add the entry for discussions at
https://wiki.php.net/rfc/shortsyntaxforarrays but I cannot edit anymore.
Would it be too much to ask to have them
Thanks, I also don't think that was the case.
Regards,
David
On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson phi...@roshambo.org wrote:
On May 31, 2011, at 11:05 PM, dukeofgaming wrote:
Hi,
I remember having wiki editing privileges not so long ago, I was going to
enter and add the
dukeofgaming wrote:
I thought it might be interesting for all to read some feedback I got
from some questions I made to the Joomla community, specifically, the
guys and gals that have been implementing the decoupling of the Joomla
framework: the Joomla Platform.
They currently still use svn
On 1 June 2011 12:41, Lester Caine les...@lsces.co.uk 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
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
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 dukeofgam...@gmail.com wrote:
Thanks, I also don't think that was the case.
Regards,
David
On Wed, Jun 1, 2011 at 1:26 AM, Philip Olson
On Wed, Jun 1, 2011 at 2:37 AM, Lester Caine les...@lsces.co.uk 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
+1 from me to *any* of the short-form suggestions (JSON or otherwise).
On 31 May 2011 19:42, Brian Moon br...@moonspot.net wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
(http://markmail.org/message/fx3brcm4ekh645se) and on Twitter where
2011/5/31 Brian Moon br...@moonspot.net:
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
On Tue, May 31, 2011 at 8:42 PM, Brian Moon br...@moonspot.net 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
-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
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 m.f...@leedsmet.ac.uk wrote:
-Original Message-
From: ekne...@gmail.com [mailto:ekne...@gmail.com] On Behalf Of
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 dukeofgam...@gmail.com wrote:
After that argument, I think I'm against : now too. +1 to =
Could { } be implemented for objects too then?.
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:
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'].'}'); // !!! Security
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 possible.
hi,
On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov dmi...@zend.com 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
On Wed, Jun 1, 2011 at 1:12 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Wed, Jun 1, 2011 at 1:07 PM, Dmitry Stogov dmi...@zend.com 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
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
2011/5/31 Brian Moon br...@moonspot.net:
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
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,
On Wed, Jun 1, 2011 at 1:45 PM, Ilia Alshanetsky i...@prohost.org 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
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 patrick.alla...@gmail.com:
2011/5/31 Brian Moon br...@moonspot.net:
Em Tue, 31 May 2011 19:42:18 +0100, Brian Moon br...@moonspot.net
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
* 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 much
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
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
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, trollsco 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 marcel.es...@croscon.com wrote:
My
On 2011-05-31, Brian Moon br...@moonspot.net 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
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 sebast...@php.net 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,
On Wed, Jun 1, 2011 at 6:04 AM, Gustavo Lopes glo...@nebm.ist.utl.pt wrote:
On Tue, 31 May 2011 22:41:36 +0100, Hannes Landeholm landeh...@gmail.com
wrote:
Agree with Derick, strictly speaking, in maths science, INF != INF.
I disagree,based on quote from
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 and new
Sounds reasonable.
2011/6/1 Johannes Schlüter johan...@schlueters.de:
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
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
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
hi,
2011/6/1 Johannes Schlüter johan...@schlueters.de:
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
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 i...@prohost.org:
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
+1
On Tue, May 31, 2011 at 1:42 PM, Brian Moon br...@moonspot.net 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
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
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):
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates s...@seancoates.com 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
On Jun 1, 2011, at 7:30 AM, Ilia Alshanetsky wrote:
On Wed, Jun 1, 2011 at 4:27 PM, Sean Coates s...@seancoates.com 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
You probably need to reset your password.
I had the same issue previously.
On Wed, Jun 1, 2011 at 4:50 AM, dukeofgaming dukeofgam...@gmail.com 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,
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
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 make it more
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
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
On Wed, Jun 1, 2011 at 6:47 PM, Dmitry Stogov dmi...@zend.com 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,
Reminder: Pls add your votes here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote
On Tue, May 31, 2011 at 8:42 PM, Brian Moon br...@moonspot.net wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
Since this was brought again recently by Rasmus
Hello,
On Wed, Jun 1, 2011 at 10:19 AM, Pierre Joye pierre@gmail.com 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
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 news
Hi Lester,
On Wed, Jun 1, 2011 at 11:19 AM, Lester Caine les...@lsces.co.uk 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 vote.
On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye pierre@gmail.com 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,
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 dukeofgam...@gmail.com wrote:
On Wed, Jun 1, 2011 at 12:19 PM, Pierre Joye pierre@gmail.com wrote:
Reminder:
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 that have any karma
On Wed, Jun 1, 2011 at 9:38 PM, Philip Olson phi...@roshambo.org 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
On Wed, Jun 1, 2011 at 2:38 PM, Philip Olson phi...@roshambo.org 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?.
I
On Wed, Jun 1, 2011 at 9:43 PM, dukeofgaming dukeofgam...@gmail.com 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
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 phi...@roshambo.org 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
On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre@gmail.com 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
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
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 mike...@gmail.com wrote:
On Wed, Jun 1, 2011 at 1:01 PM, Pierre Joye pierre@gmail.com wrote:
5 character difference for each array being saved. That's it. At the
expense of syntax highlighters, IDEs, books, all becoming outdated and
Hello,
On Wed, Jun 1, 2011 at 2:17 PM, Anthony Ferrara ircmax...@gmail.com 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
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),
'unluckyNumbers' =
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
On Wed, Jun 1, 2011 at 11:59 PM, John Crenshaw johncrens...@priacta.com 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
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
On Wed, Jun 1, 2011 at 3:09 PM, Sean Coates s...@seancoates.com 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
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
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:
On Thu, Jun 2, 2011 at 12:10 AM, Zeev Suraski z...@zend.com 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
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 need to
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
On Thu, Jun 2, 2011 at 12:22 AM, Marcel Esser marcel.es...@croscon.com 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
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
-
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
hi Chris
On Thu, Jun 2, 2011 at 12:34 AM, Christopher Jones
christopher.jo...@oracle.com 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
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
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
hi David,
On Thu, Jun 2, 2011 at 12:47 AM, David Zülke
david.zue...@bitextender.com 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
1 - 100 of 106 matches
Mail list logo
