Hello, PHP developers,
I'm new to the list, but have been using PHP for a number of years, have
done a little hacking in the source code, and have an interest in the
development of the language.
Particularly recently I have been reading with a good deal of excitement
Stefan Marr's RFC on
Hi Guilherme
You wrote that Java spec? Cool! Also very nice example of the PHP
EBNF! I think PHP needs a canonical one of those and that the parser
should be rewritten to represent said EBNF. Thats what I'm dreaming of
at least :)
Cheers
Rune
On Sat, Jan 1, 2011 at 5:23 PM,
Nonetheless, it's a significant undertaking to deal with the complexity of
the language. There are dozens of tiny little edge cases in PHP's parsing
that require bunches of extra parser rules. An example from above is the
difference between using statement and inner-statement for the two
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Your application broke because of a deprecation warning? Are you
sending PHP errors to the user in your production code?
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such
Hi!
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdout per default, instead of syslog ? ;-o
You should use settings based on php.ini-production in production. One
of these is display_errors=Off.
* James Butler james.but...@edigitalresearch.com wrote:
As a 'grown up' you should never expect changes to a system
to just work without testing, any change introduces risk,
you need to mitigate against that risk by testing.
True, but applications should be designed in a way that minimizes
On 1/2/11 4:52 PM, Enrico Weigelt wrote:
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Your application broke because of a deprecation warning? Are you
sending PHP errors to the user in your production code?
Unfortunately, yes. I didn't enable that - happend magically
on the update.
* Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
IIRC many deprecation warnings, which totally broke the output.
Err, you actually output the warnings in your output? In production?!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed
* Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
Unfortunately, yes. I didn't enable that - happend magically
on the update. That's yet another strange point here - why do
such warnings go stdout per default, instead of syslog ? ;-o
You should use settings based on php.ini-production in
On 1/2/11 5:14 PM, Enrico Weigelt wrote:
* Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
IIRC many deprecation warnings, which totally broke the output.
Err, you actually output the warnings in your output? In production?!
Something seem to turn them on magically, no idea what it was.
On Mon, 03 Jan 2011 01:14:42 -, Enrico Weigelt weig...@metux.de
wrote:
* Stas Malyshev smalys...@sugarcrm.com wrote:
Of course, nobody personally has any time. But PHP is a volunteer
project, so if nobody has the time, nobody should complain about php
developers not caring. PHP
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Also, you said this happened between 5.3.2 and 5.3.3? Looking through
the diff between those two versions we did not add any new deprecation
warnings. We tend to not do that in a minor release. At least I don't
recall the last time we did so.
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Nope, we really didn't change anything. The simple explanation is
that you installed without or with a different php.ini from the
previous version.
Of course, I've kept my original (old) config and just adapted
some things to the new default config
On 1/2/11 5:45 PM, Enrico Weigelt wrote:
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Nope, we really didn't change anything. The simple explanation is
that you installed without or with a different php.ini from the
previous version.
Of course, I've kept my original (old) config and just
Hi!
Something seem to turn them on magically, no idea what it was.
(perhaps the config variable name changed ? ;-o)
No, it has not. Whatever magically changed on your system was not
caused by PHP. On the other hand it gave you a chance to fix a serious
configuration problem on your server,
Hi!
In essence you say here, that I should diff the production config
example from one version to another to find out what changed
No. You should use it now and should always have used it. There was no
change in this config parameter at least since 5.3.0. Look in the public
SVN repo if you
Am 03.01.2011 02:19, schrieb Enrico Weigelt:
In essence you say here, that I should diff the production config
example from one version to another to find out what changed
and adapt my config, on each update.
Hm thats your job as sysadmin
Adds about 15mins extra work
What is your job
per
On 12/12/10 01:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a trait is to use
either abstract set/get
On 3/01/11 2:24 PM, David Muir wrote:
On 12/12/10 01:47, Stefan Marr wrote:
Hi:
Traits do not provide any special provisioning for handling properties,
especially, there is no language solution for handling colliding property names.
The current solution/idiom for handling state safely in a
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
* Rasmus Lerdorf ras...@lerdorf.com wrote:
Also, you said this happened between 5.3.2 and 5.3.3? Looking through
the diff between those two versions we did not add any new deprecation
warnings. We tend to not do that in a minor release. At least
Am 03.01.2011 02:41, schrieb Enrico Weigelt:
No, as usual on Gentoo, config files are never overwritten, but
written to another place and tools like etc-update show you the
differences. I've merged the configs manually, and I'm pretty
sure I didn't add anything like error_reporting=On,
21 matches
Mail list logo
