Hi!
it should actually be a hard error. As we always claim PHP follows pure
IS-A relation ships.
I feel very uneasy with hard errors on something that is not indeed an
error preventing engine from continuing. I.e. my (personal) opinion is
that if the engine can move forward, even with some
The second and final release candidate of 5.2.9 was just released for
testing and can be downloaded here:
http://downloads.php.net/ilia/php-5.2.9RC2.tar.bz2 (md5sum:
253befc2627abb09a5888b1e6ad84077)
http://windows.php.net/downloads/qa/php-5.2.9RC2-Win32-VC6-x86.zip
(sha1: 3cbf5b410131cd11
On 12.02.2009, at 18:17, Leon KUKOVEC wrote:
Hi all,
A while back I published a patch for PHP 5.2 and SNMP. Anyone had time
to review it
and if so, any comments? Could this patch be considered as a PHP 5.3
TODO item?
Anything I need to do to accept the patch?
Err did you open a bug tick
On 12.02.2009, at 21:59, Arnaud Le Blanc wrote:
On Wed, 2009-02-11 at 18:07 +0100, Lukas Kahwe Smith wrote:
- pcntl_signal needs declare(ticks) which is deprecated since 5.3
I marked this as a documentation issue. This has been discussed when
it
was decided to deprecate ticks. Although it
Hi,
On Wed, 2009-02-11 at 18:07 +0100, Lukas Kahwe Smith wrote:
> - pcntl_signal needs declare(ticks) which is deprecated since 5.3
I marked this as a documentation issue. This has been discussed when it
was decided to deprecate ticks. Although it would be great to keep
ticks, at least for use wi
See the results of the following on 5.2.6, 5.2.9rc2 and 5.3:
php -r '$a[1e100] = 1; var_dump($a);'
5.2.6:
array(1) {
[-2147483648]=>
int(1)
}
5.2.9rc2:
array(1) {
[-1]=>
int(1)
}
5.3:
array(1) {
[2147483647]=>
int(1)
}
I doubt the result of 5.2.9rc2 is quite what we expect, and t
Lukas Kahwe Smith wrote:
The following remain open and it does not seem someone is actively
working in it:
- PHP_5_3 missed merge from PHP_5_2 for write_func callback
Seeing as I have an interest in this getting in 5_3, I'll work up a patch for
this unless someone wants to speak up that they'
Hi Steph:
> I'm talking about the UPGRADE file in the source, which is plain text.
AH! Pardon the misunderstanding. Yeah, it seems that file should be
short and sweet then point folks to the manual.
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
Hi all,
A while back I published a patch for PHP 5.2 and SNMP. Anyone had time
to review it
and if so, any comments? Could this patch be considered as a PHP 5.3 TODO item?
Anything I need to do to accept the patch?
Thanks.
--
Best Regards,
Leon
--
PHP Internals - PHP Runtime Developm
It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.
I'm talking about the UPGRADE file in the source, which is plain text.
Have you ever tried to read it?
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, vi
Hi Steph:
> It's nothing to do with structure. "Everything" makes for a very long
> file, full stop.
It doesn't matter that the XML file is long. Each section is broken up
into a separate page in the manual.
You want the upgrade guide to contain just the things that will cause
difficulties u
Hey,
I guess the patch relies on the 5.3's DVAL_TO_LVAL behavior that was
changed by the fix for bug #42868, right?
If so, this patch shouldn't be MFH'ed as the #42868 patch was not
merged although I didn't remember any discussion on this.
See also: http://marc.info/?l=php-internals&m=12079972092
BUT perhaps some of the more complex explanations should have their own
document. If it 'requires more explanation than we want to provide in
the documentation' that does seem to suggest that a development perhaps
DOES need better doumentation?
In the manual, really. But - quite.
- Steph
--
Hi Dan,
Because the guide is in the manual. The manual is the difinitive source
on how to use PHP.
The guide was only added directly into the manual quite recently. This is
exactly what I'm trying to say; its purpose has shifted since it became part
of the manual and it's lost whatever usef
So in summary, I feel the key point for this document is:
- a single document that lists all changes
- contains pointers that enables someone to look up more details in the
documentation
- enables people who get new "strange" error messages to find pointers
towards the documentation
- some leng
Then I guess I need to read the archives.
I can't imagine why a system admin would give a damn about new
language features, object model, reference changes, pdo, new error
levels or how to check if a class inherits another class.
They'd need to know that there had been major changes in the langu
Lukas Kahwe Smith wrote:
Hey Steph,
Personally I think we should list all changes. For certain changes we
should devote some explanations (like E_DEPRECATED). For the most part I
see this document as a place where we provide an overview of things
which then gives them the right key word to lo
17 matches
Mail list logo
