On Thu, Jun 2, 2011 at 12:09 AM, Sean Coates s...@seancoates.com wrote:
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
On Jun 1, 2011, at 7:35 AM, Derick Rethans wrote:
But only if you keep it consistent, PHP has always been using = for
key/val association, I don't see any reason to suddenly provide key:
val, unless what you want is to confuse people.
Yes, definitely = vs. : in any case.
+1 to this.
--
2011/6/2 Sanford Whiteman swhitemanlistens-softw...@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
-Original Message-
From: Michael Shadle [mailto:mike...@gmail.com]
Sent: 01 June 2011 21:37
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
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote:
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all about their release process. There are
On Thu, Jun 02, 2011 at 08:21:37AM +, Ford, Mike wrote:
Back on the soapbox. All of this is just to reduce typing array (5
characters) before things?
Not here. For me, the shorter syntax is simply an order of magnitude
more readable. I really don't care how much typing is involved
+1
On 02/06/11 17:23, Pierre Joye wrote:
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote:
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's nothing random at all
Am 02.06.2011 11:36, schrieb David Muir:
That said, I'm not sure if an LTS is a good idea. One of the biggest
frustrations for me as a developer is hosts taking forever to upgrade to
newer versions of PHP. Most hosts I've seen are still on 5.2, and some
don't seem to have plans of upgrading
-Original Message-
From: John Crenshaw [mailto:johncrens...@priacta.com]
Sent: 01 June 2011 23:00
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
On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote:
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote:
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused about the distro suggestion. I think Ubuntu was the example, and
there's
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
Array and in most of the case, this is a sign of an error.
Let me know about your feelings.
Patch implementing that behavior change:
On Thu, Jun 02, 2011 at 12:19:36PM +0200, Patrick ALLAERT wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
Array and in most of the case, this is a sign of an error.
Am 02.06.2011 12:19, schrieb Patrick ALLAERT:
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
what is new?
a fatal error would be better here
error_reporting = E_ALL | E_STRICT
google: Notice: Array to string conversion
signature.asc
Description:
Am 01.06.2011 14:44, schrieb Johannes Schlüter:
I mentioned this before: I like the Ubuntu model:
* One development branch for the next version
* One current version
* One long term supported version
+1
The current version is aimed to give early access to new features, to
avoid cases
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
Array and in most of the case, this is a sign of an error.
Let me know about your feelings.
Patch implementing that behavior change:
On Thu, Jun 2, 2011 at 11:51 AM, Peter Lind peter.e.l...@gmail.com wrote:
On 2 June 2011 10:23, Pierre Joye pierre@gmail.com wrote:
On Thu, Jun 2, 2011 at 7:32 AM, Peter Lind peter.e.l...@gmail.com wrote:
Sorry for jumping into the thread, but I couldn't help noting that you seem
confused
On Thu, Jun 2, 2011 at 12:08 PM, Sebastian Bergmann sebast...@php.net wrote:
The current version is aimed to give early access to new features, to
avoid cases like traits which take years to come out while a bit more
conservative users (and maybe distros) may stay on the LTS.
Traits is a
2011/6/2 Ford, Mike m.f...@leedsmet.ac.uk:
-Original Message-
From: John Crenshaw [mailto:johncrens...@priacta.com]
Sent: 01 June 2011 23:00
skip
4. The format most consistent with other languages is JSON
Again, matter of experience. Last time I counted, I'd used upward of
30
On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:
*snip*
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros given that it is a distro with an insane amount of totally
unrelated
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:
*snip*
No, it is the same that what we proposed. What we proposed is that
every release is actually a LTS release. What Ubuntu uses works fine
for distros
On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote:
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:
*snip*
No, it is the same that what we proposed. What we proposed is that
every release is
On Thu, Jun 2, 2011 at 1:15 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 2 June 2011 13:03, Pierre Joye pierre@gmail.com wrote:
On Thu, Jun 2, 2011 at 1:01 PM, Peter Lind peter.e.l...@gmail.com wrote:
On 2 June 2011 12:40, Pierre Joye pierre@gmail.com wrote:
*snip*
No, it is the
Am 02.06.2011 13:15, schrieb Peter Lind:
Anyway, I'll stop it here, as I doubt I'll convince you of anything
(and vice versa).
Just one thing to add: thanks for the work on PHP :) Much appreciated.
I think/hope that this RFC is a step in the right direction to make the
release process
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
Array and in most of the case, this is a sign of an
I don't there's a good general case for this. I'd +1 on throwing E_NOTICE.
Hannes
On 2 June 2011 13:54, Hannes Magnusson hannes.magnus...@gmail.com wrote:
How about making it useful rather then just throwing an notice?
Recursive implode maybe? Or json/php serialized? :)
-Hannes
--
PHP
Em Thu, 02 Jun 2011 12:54:10 +0100, Hannes Magnusson
hannes.magnus...@gmail.com escreveu:
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net
wrote:
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it
Am 02.06.2011 13:54, schrieb Hannes Magnusson:
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
this conversion should never happen and throw a fatal error since this
action is destructive to data and never useful nor will warnings/notices
helps in the real world
Unlike i.e. Python its really not the PHP way to go fatal on the
developer during weird type conversions. I'm also +1 on the
Am 02.06.2011 14:56, schrieb Rune Kaagaard:
this conversion should never happen and throw a fatal error since this
action is destructive to data and never useful nor will warnings/notices
helps in the real world
Unlike i.e. Python its really not the PHP way to go fatal on the
developer
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote:
Am 02.06.2011 13:54, schrieb Hannes Magnusson:
On Thu, Jun 2, 2011 at 12:11, Patrick ALLAERT patrickalla...@php.net
wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a
Am 02.06.2011 15:04, schrieb John LeSueur:
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote:
First, I agree that converting to json/imploding would be a bad idea.
There's no guarantee that the developer wanted to use the array in that way,
or even
that he wanted to
3 yes please.
Sent from my iBrain, powered by Panda.
On Jun 2, 2011, at 6:19 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following
E_NOTICE. The current conversion is so completely useless, that whenever it
happens, it is almost certainly an error. Any implicit conversion here would
perpetuate problems in code that was probably wrong in the first place.
John Crenshaw
Priacta, Inc.
-Original Message-
From: John
2011/6/2 Hannes Magnusson hannes.magnus...@gmail.com:
How about making it useful rather then just throwing an notice?
Recursive implode maybe? Or json/php serialized? :)
As already mentioned, that would be a much bigger BC break which would
requires RFC, voting, ...
Not that I am against, the
hi,
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
Cheers,
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT patrickalla...@php.net wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
2011/6/2 Rune Kaagaard rumi...@gmail.com:
this conversion should never happen and throw a fatal error since this
action is destructive to data and never useful nor will warnings/notices
helps in the real world
Unlike i.e. Python its really not the PHP way to go fatal on the
developer during
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERTpatrickalla...@php.net wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a
2011/6/2 Reindl Harald h.rei...@thelounge.net:
Am 02.06.2011 15:04, schrieb John LeSueur:
On Thu, Jun 2, 2011 at 6:24 AM, Reindl Harald h.rei...@thelounge.netwrote:
First, I agree that converting to json/imploding would be a bad idea.
There's no guarantee that the developer wanted to use the
2011/6/2 Brian Moon br...@moonspot.net:
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERTpatrickalla...@php.net
wrote:
Hi,
I would like to introduce an
Even though I have quite mixed feelings about this, I think I am
finally ready to cast
my +1. Over the past few days I've discussed with a few people and
noticed the need, or rather a strong desire to have this feature in
PHP and most people seemed to care only little about how it was done
as long
On Thu, Jun 02, 2011 at 04:07:25PM +0200, Patrick ALLAERT wrote:
Not true. Here is a valid example that would break after implementing
this as en error.
if ($x == Array) {
array_walk( $x, print_r );
}
I'm not saying that this is good code, I'm only saying that this would
break BC
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value,
but I actually received an array, this would mean I need to now
explicitly check for it, since it will stop the runtime otherwise. Example:
On Thu, 02 Jun 2011 15:38:00 +0200, Brian Moon br...@moonspot.net wrote:
I like this for the current stable branch, no bc impact and gives a
way to detect such mistakes (not ideal but better than nothing).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick
ALLAERTpatrickalla...@php.net wrote:
Hi,
I
Hi all,
I've just read the Release Process RFC
(https://wiki.php.net/rfc/releaseprocess) and have a suggestion
regarding this part of the version numbering scheme: x.y.z to
x.y+1.z.
I believe x.y.z to x.y+1.0 is much more clear and common and less of
a departure from the current numbering
+1
Sent from my iPhone
On Jun 2, 2011, at 4:19 AM, Patrick ALLAERT patrick.alla...@gmail.com wrote:
Hi,
I would like to introduce an E_NOTICE when an array is silently
converted to a string.
This isn't very useful as it constantly produces the following string:
Array and in most of the
The choice between E_WARNING and E_NOTICE is simple if we look at the
definitions of the levels
(http://php.net/manual/en/errorfunc.constants.php).
E_NOTICE is defined as Run-time notices. Indicate that the script
encountered something that could indicate an error, but could also
happen in the
Am 02.06.2011 16:24, schrieb Marcel Esser:
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value, but I
actually received an array, this would
mean I need to now explicitly check for it, since it will stop the
You don't need a form to receive bad user input.
Also, I am not really inclined to write $v = isset($_POST['x']) ?
(is_array($_POST['x']) ? 'something else that makes more sense' :
$_POST['x'] ) : null; just to avoid catching a fatal.
- M.
On 6/2/2011 10:50 AM, Reindl Harald wrote:
Am
On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote:
Am 02.06.2011 16:24, schrieb Marcel Esser:
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value, but I
actually received an array, this would
mean
Am 02.06.2011 14:56, schrieb Rune Kaagaard:
this conversion should never happen and throw a fatal error since this
action is destructive to data and never useful nor will warnings/notices
helps in the real world
I agree totally that such a conversion should never happen. If we could
redesign
first rule of programming: sanitize user input
if you EXPECT no array catch it
Am 02.06.2011 16:54, schrieb Marcel Esser:
You don't need a form to receive bad user input.
Also, I am not really inclined to write $v = isset($_POST['x']) ?
(is_array($_POST['x']) ? 'something else that
makes
On Jun 2, 2011, at 8:01 AM, Peter Lind wrote:
On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote:
Am 02.06.2011 16:24, schrieb Marcel Esser:
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value,
I agree entirely.
Let me go ahead and fix these three billion man hours worth of code in
use through-out the world. I'll be back shortly.
- M.
On 6/2/2011 11:19 AM, Reindl Harald wrote:
first rule of programming: sanitize user input
if you EXPECT no array catch it
Am 02.06.2011 16:54,
Am 02.06.2011 17:01, schrieb Peter Lind:
On 2 June 2011 16:50, Reindl Harald h.rei...@thelounge.net wrote:
Am 02.06.2011 16:24, schrieb Marcel Esser:
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value, but I
I'm pretty sure you've never seen my code, so I am not going to comment
on that.
However, speaking not just for myself, two ternary operations and two
functions calls to just prevent a stoppage code of execution, never mind
input filtering for a second, is not entirely reasonable considering
may I suggest to both of you to continue this rant off line please?
The initial question was rather simple and only about this specific
case. And we seem to agree on the necessity to have a notice/warning
here. That's the maximum we can do at this stage, both for 5.3 and
5.4.
On Thu, Jun 2, 2011
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
horribly slow and a couple of them can be replaced by the
TSRMLS_DC/CC, if I'm not mistaken.
For the windows side, I do not have the time to do the equivalent, so
if you commit the patch to trunk first so I can fix the
Could we first go out with fully JSON compatible version for 5.4?
and then later decide the = stuff based on how that worked.
Native JSON is a big stuff for userland, and I'm pretty sure it will bring a
hole of core version upgrades.
Martin Scotta
On Wed, Jun 1, 2011 at 7:09 PM, Sean Coates
reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
Thanks,
On Tue, May 31, 2011 at 8:42 PM, Brian Moon br...@moonspot.net wrote:
https://wiki.php.net/rfc/shortsyntaxforarrays
--
Pierre
@pierrejoye |
2011/6/2 Reindl Harald h.rei...@thelounge.net:
Am 02.06.2011 16:24, schrieb Marcel Esser:
I am not convinced that making this an error is a good idea.
If I receive a $_GET/$_POST value that I expect to be a string value, but I
actually received an array, this would
mean I need to now
On 05/31/2011 03:30 PM, Ilia Alshanetsky wrote:
Since we are on the topic of reviewing past RFCs for 5.4, can we take
another look at the Zend Signals RFC:
https://wiki.php.net/rfc/zendsignals
The patch is solid (have been using it in production for quite some
time) and improvement is quite
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
On Thu, Jun 2, 2011 at 6:04 PM, Pierre Joye pierre@gmail.com wrote:
hi Ilia,
I would suggest to kill the TSRMLS_FETCH while being at it. They are
I like the idea of an error message when this happens, but as few
other people in the thread had mentioned, I think it should be a
warning (E_WARNING) because the conversion results in data loss
(content of the array is replaced with Array string).
On Thu, Jun 2, 2011 at 12:11 PM, Patrick ALLAERT
On Thu, Jun 2, 2011 at 7:10 PM, Ilia Alshanetsky i...@prohost.org wrote:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-)
I mean in this patch only. This patch adds a couple, so it can be done
at the same time (afair these functions are not used heavily
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in killing it as opposed to simply not use
Also matter of opinion, and of experience. Apart from the fact that
my use of jQuery amounts to a few weeks out of a (mumble)-year
programming career, no I don't use pure JSON for it - Javascript
object literals, yes, but not pure JSON.
It's not just you. The claim that people
There's no need to be rude. If you can't make your point without attacking
people, then you need a better argument.
JSON in this case just means a simple object notation using {, [, and :. You
know that. Yes, we're all abusing the term, just like we all abuse AJAX,
regardless of the fact that
No we can't; I already explained why in another email last night. Copypasta:
json_decode() can deal with Unicode sequences because decodes to UTF-8. That is
not possible in a language construct:
What if I do this, in a latin1 encoded file:
$x = {foo: ä, bar: \u0123}
Should that then give
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work based on an sqllite database?
I have a local install but only full function names match but something
like
http://localhost/phpman/manual-lookup.php?pattern=str
does not. A quick
pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
If people vote on this now, will further discussion about how this SHOULD work
be shut down with we already voted on this?
S
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.
The RFC is about short array syntax and as far as I can see there is
already a clear consensus for one of the proposed new syntax.
Cheers,
On Thu, Jun 2, 2011 at 9:53 PM,
so put +1 on both :D
On Thu, Jun 2, 2011 at 9:37 PM, Brian Moon br...@moonspot.net wrote:
On 6/2/11 11:08 AM, Pierre Joye wrote:
reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
I don't really care
On 6/2/11 11:08 AM, Pierre Joye wrote:
reminder #2, pls do vote here:
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
I don't really care which syntax wins as long as one of them gets rolled in.
Brian.
--
PHP Internals - PHP Runtime
There's no need to be rude. If you can't make your point without
attacking people, then you need a better argument.
If you can't make your point without misusing terms to the point of
making yourself untrustworthy on that level alone, stop trying to
argue.
The lazy programmer axiom
Hi!
https://wiki.php.net/rfc/shortsyntaxforarrays/vote some devs still did
not choose which syntax they want.
Just to be clear on my vote, I'd really like to have [], and I think we
MUST keep = there, but I don't care either way about ':'.
--
Stanislav Malyshev, Software Architect
SugarCRM:
If people vote on this now, will further discussion about how this SHOULD
work be shut down with we already voted on this?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.
The RFC is about short array syntax and as
Stop spreading FUD, please.
It's no different than writing json_decode(ä\u0123).
Your statement, the stuff in bar in UTF-8 is wrong. The \u0123
escape sequence is a representation of a Unicode character, not the
character itself. This representation can be encoded in any
ASCII-compatible
Hi!
We're having pretty lively discussion on the list, twitter and other
places, but let's not forget the big goal of 5.4 :)
1. First of all, the official business. Any objections to the RMs for
5.4 being:
Stas Malyshev (stas)
David Soria Parra (dsp)
If not, we'll be the 5.4 RM team.
2.
On Jun 2, 2011, at 1:19 PM, Sean Coates wrote:
If people vote on this now, will further discussion about how this SHOULD
work be shut down with we already voted on this?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a couple) likes or wants it.
hi,
I have no objection as long as the RFC for the release process is
adopted before we do any 5.4 releases, as stated earlier, this is the
only way to put ourself on the safe side.
Cheers,
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
We're having pretty
On Thu, Jun 2, 2011 at 10:19 PM, Sean Coates s...@seancoates.com wrote:
If people vote on this now, will further discussion about how this SHOULD
work be shut down with we already voted on this?
which other discussions do you wish? Json is clearly not an option and
not enough people (but a
Sounds fine to me.
On Thu, Jun 2, 2011 at 10:24 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
We're having pretty lively discussion on the list, twitter and other places,
but let's not forget the big goal of 5.4 :)
1. First of all, the official business. Any objections to the RMs for
On Thu, Jun 2, 2011 at 22:24, Stas Malyshev smalys...@sugarcrm.com wrote:
I'd like to set up a vote for the undecided TODO features on wiki.php.net,
anybody could help me with setting up the voting module there if there's
such thing on the wiki? Or set me up with the access to wiki machine and
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote:
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work based on an sqllite database?
https://wiki.php.net/doc/phd/view
Please ask any followup questions on the
Hannes Magnusson hannes.magnus...@gmail.com writes:
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote:
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work based on an sqllite database?
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
Hannes Magnusson hannes.magnus...@gmail.com writes:
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote:
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work
On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson phi...@roshambo.org wrote:
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
Hannes Magnusson hannes.magnus...@gmail.com writes:
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com
wrote:
Could some kind soul advise me on
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I am all for killing
TSRMLS_FETCH.
Is there any advantage in
Nathan Nobbe quickshif...@gmail.com writes:
On Thu, Jun 2, 2011 at 4:01 PM, Philip Olson phi...@roshambo.org wrote:
On Jun 2, 2011, at 2:46 PM, Richard Riley wrote:
Hannes Magnusson hannes.magnus...@gmail.com writes:
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com
State the case for JSON in a separate RFC and progress will be made, but I
think there is a fundamental mistake here: serialization formats are the
*means* for interoperability, not the ends.
The only way I see JSONy syntax would help is if PHP code —with JSONy
syntax— would be parsed by a JSON
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
at a time please ;-) And for the record I
2011/6/2 Felipe Pena felipe...@gmail.com
Hi,
2011/6/2 Michael Maclean mich...@no-surprises.co.uk
On 02/06/11 18:20, Gustavo Lopes wrote:
Em Thu, 02 Jun 2011 18:10:50 +0100, Ilia Alshanetsky i...@prohost.org
escreveu:
Killing TSRMLS_FETCH is a noble goal, but let's keep it to once patch
On 05/15/2011 02:45 AM, Rasmus Lerdorf wrote:
As you may have noticed, I have fixed the autoconf stuff to work with autoconf 2.60+
in PHP_5_4 and trunk. In the past I have tried to make it support both 2.60 and
=2.60 at the same time and it never worked. autoconf 2.60 was released in June
Hi,
A while ago I submitted a patch to allow session_set_save_handler() to
accept a class, and support the inheritance of the default session
handler's methods.
The RFC has a more detailed description and the current patch:
https://wiki.php.net/rfc/session-oo
Changes since this was last
I'm on a plane headed for Rio, so I can't test your patch for a while. If you
have checked it on a couple of different systems, commit it, and we will work
out any issues during the early stages of getting 5.4 out the door.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To
Hannes Magnusson hannes.magnus...@gmail.com writes:
On Thu, Jun 2, 2011 at 21:03, Richard Riley rile...@googlemail.com wrote:
Could some kind soul advise me on how to install php docs localy and
have the excellent patterns search work based on an sqllite database?
On 6/2/11 6:44 PM, Rasmus Lerdorf wrote:
I'm on a plane headed for Rio, so I can't test your patch for a while. If you
have checked it on a couple of different systems, commit it, and we will work
out any issues during the early stages of getting 5.4 out the door.
-Rasmus
I'll test it on
97 matches
Mail list logo
