On Sat, Apr 18, 2009 at 23:48, Nuno Lopes nlop...@php.net wrote:
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
?php $a = array();
The issue here is that the old code only looked at the main
Last I checked it was working properly, are you sure you are using the
latest version? I think we even have a test case around this bug.
Ilia Alshanetsky
On 19-Apr-09, at 7:09 AM, Hannes Magnusson wrote:
On Sat, Apr 18, 2009 at 23:48, Nuno Lopes nlop...@php.net wrote:
The original code
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at 17:57, Ilia Alshanetsky i...@prohost.org wrote:
Last I checked it was working properly, are you sure you are
Are you using CGI or CLI sapi?
Ilia Alshanetsky
On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests
with it.
Then diff the run-tests to see the workaround in 5.3.
-Hannes
On Sun, Apr 19, 2009 at
CLI
-Hannes
On Sun, Apr 19, 2009 at 18:21, Ilia Alshanetsky i...@prohost.org wrote:
Are you using CGI or CLI sapi?
Ilia Alshanetsky
On 19-Apr-09, at 12:16 PM, Hannes Magnusson wrote:
I'm pretty sure yes.
Try copying the run-tests.php from 5_2 to 5_3 and run the PDO tests with
it.
The original code actually can be found inside php_cli.c and there it
only checked the 1st line for '#'. if you create a file such as:
#1
#2
?php $a = array();
The issue here is that the old code only looked at the main script, now
included files ar affected, too.
So either we check in the
Christopher Jones wrote:
Stanislav Malyshev wrote:
Hi!
I'm looking forward to reading at least a mail note describing what
extension
maintainers can/can't do with this.
Basically you can make your Zend extension load with any API number
and any build ID (or let it decide with which ID
Dmitry Stogov wrote:
Is this Zend extensions only?
Yes.
Is it safe to set in extensions that should
work with pre 5.3 PHP's?
Yes, in php5.2 and below build_id just won't be checked ans this
callback won't be called.
Did I lose track of the other API versioning change - the one that was
Stanislav Malyshev wrote:
Hi!
I'm looking forward to reading at least a mail note describing what
extension
maintainers can/can't do with this.
Basically you can make your Zend extension load with any API number and
any build ID (or let it decide with which ID to load and with which one
Hi Dmitry,
I had looked at this Bug and wondering whether it should be fixed (I guess
the answer is yes :-)) and how to do so. I was only thinking along the
lines of adding a stack to keep track of multiple heredocs in the scanner.
Then I saw your fix and thought it was a cool method and
Hello,
On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
helly Fri Aug 8 17:10:49 2008 UTC
Modified files:
/php-src/main main.c php.h
/ZendEngine2zend.h zend_API.c zend_execute_API.c zend_vm_def.h
zend_vm_execute.h
Hello,
On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss [EMAIL PROTECTED] wrote:
Hello,
On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
helly Fri Aug 8 17:10:49 2008 UTC
Modified files:
/php-src/main main.c php.h
/ZendEngine2zend.h
On Fri, Aug 8, 2008 at 21:54, Etienne Kneuss [EMAIL PROTECTED] wrote:
Forgot to mention it: there is something weird in mysqli_driver.c, I
don't know what the author's original intention was, but it looks
wrong.
c.f. FIXME
I think I already filed a bug report about that some months ago, I
Hello Etienne,
Friday, August 8, 2008, 9:54:49 PM, you wrote:
Hello,
On Fri, Aug 8, 2008 at 9:50 PM, Etienne Kneuss [EMAIL PROTECTED] wrote:
Hello,
On Fri, Aug 8, 2008 at 7:10 PM, Marcus Boerger [EMAIL PROTECTED] wrote:
helly Fri Aug 8 17:10:49 2008 UTC
Modified files:
Marcus Boerger kirjoitti:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we
On 27.07.2008, at 02:58, Marcus Boerger wrote:
Hello Internals,
apparently overloaded objects do not need to implement property
access
and we issue an E_NOTICE in case someone tries to none-the-less.
Dmirty
thankfully made this consistent for all handlers now. However this
raised a
Hello Lukas,
Sunday, July 27, 2008, 12:00:55 PM, you wrote:
On 27.07.2008, at 02:58, Marcus Boerger wrote:
Hello Internals,
apparently overloaded objects do not need to implement property
access
and we issue an E_NOTICE in case someone tries to none-the-less.
Dmirty
thankfully
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we should increase the
Marcus Boerger escribió:
Hello Internals,
apparently overloaded objects do not need to implement property access
and we issue an E_NOTICE in case someone tries to none-the-less. Dmirty
thankfully made this consistent for all handlers now. However this raised a
question on my side, whether we
Derick,
Thank you for bug report.
I found a very sinple scipt (t1.php, shown below)
causes segmentation error or stack error
using PHP 5.3 compiled with --enable-zend-multibyte.
It works fine with PHP 5.2.
php.ini
---
mbstring.internal_encoding = UTF-8
mbstring.script_encoding = SJIS
--
t1.php
On Sat, 5 Jul 2008, Rui Hirokawa wrote:
Thank you for bug report.
I found a very sinple scipt (t1.php, shown below)
causes segmentation error or stack error
using PHP 5.3 compiled with --enable-zend-multibyte.
It works fine with PHP 5.2.
My script was malfunctioning with PHP 5.2 as well
On Sun, 29 Jun 2008, Rui Hirokawa wrote:
hirokawa Sun Jun 29 08:21:36 2008 UTC
Modified files: (Branch: PHP_5_3)
/ZendEngine2 Zend.m4 zend.c zend_compile.c zend_globals.h
zend_highlight.c zend_language_scanner.c
On Mon, 5 May 2008, Dmitry Stogov wrote:
dmitryMon May 5 09:44:07 2008 UTC
Added files:
/ZendEngine2/testsns_063.phpt
Modified files:
/ZendEngine2 zend_API.c zend_compile.c
Log:
Support for old-style
On Mon, May 5, 2008 at 12:13 PM, Derick Rethans [EMAIL PROTECTED] wrote:
On Mon, 5 May 2008, Dmitry Stogov wrote:
dmitryMon May 5 09:44:07 2008 UTC
Added files:
/ZendEngine2/testsns_063.phpt
Modified files:
/ZendEngine2 zend_API.c
On 05.05.2008 14:13, Derick Rethans wrote:
Support for old-style constructors in namespaces
Do we really want/need this?
I'm not really sure either.
5.3 seems to be perfect candidate for dropping this kind of backward
compatibility.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime
Pierre Joye escribió:
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
--
Progress is possible only if we train ourselves to think about programs
without thinking of them as pieces
Hi!
As it can't break any code out there, I would like to do not support
the old style constructors in namespace (cleanup++).
Right, this is not needed at all.
If by old-style ctors you mean this:
namespace Foo;
class Bar {
function Bar() {/* ctor! */}
}
then I think it should be
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
speed), but might break a lot of code.
Thanks. Dmitry.
Antony Dovgal wrote:
On
Hi Dmitry,
On Mon, May 5, 2008 at 8:02 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation
On Mon, 5 May 2008, Dmitry Stogov wrote:
As we didn't drop this support yet, and it didn't work in namespaces by
mistake I've fixed it to work in the same way as without namespaces.
Removing this support won't give any speedup (except of compilation speed),
but might break a lot of code.
Hi!
How can it break existing code? It's only on issue if a class is part of
a namespace, and existing code doesn't have namespaces. So it *can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy to do. Forcing people to
Hi!
code should be updated to use the normal constructor (which exists
since 4-5 years).
There's nothing not normal about using either form of constructors,
why force people to rewrite their perfectly good and working code?
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED]
It's just simple to make constructors work in the same way in namespaces
and out of them. It would be difficult to explain why the first script
prints ok and the second doesn't.
?php
class Foo {
function Foo() {
echo ok\;
}
}
new Foo();
?
?php
namesapce Bar;
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
It's just simple to make constructors work in the same way in namespaces and
out of them. It would be difficult to explain why the first script prints
ok and the second doesn't.
It is easy to explain: You have to use the
On 05.05.2008, at 20:51, Pierre Joye wrote:
On Mon, May 5, 2008 at 8:43 PM, Dmitry Stogov [EMAIL PROTECTED] wrote:
It's just simple to make constructors work in the same way in
namespaces and
out of them. It would be difficult to explain why the first script
prints
ok and the second
Hi!
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
There's nothing to cleanup. You trying to prove that this form should
be removed by representing it
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3
and remove in PHP 6.x.
There's nothing to fix, it's not broken.
--
Stanislav Malyshev, Zend Software Architect
[EMAIL PROTECTED] http://www.zend.com/
(408)253-8829 MSN: [EMAIL PROTECTED]
--
PHP Internals - PHP
On Mon, May 5, 2008 at 9:18 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Hi!
kind of stuff is quite easy to fix. Throw a deprecated warning in 5.3 and
remove in PHP 6.x.
There's nothing to fix, it's not broken.
Ok, point made. Once again a you vs all other thread, no thanks, I
pass
On 5/5/08, Pierre Joye [EMAIL PROTECTED] wrote:
We can then even drop the old form in php 6.x. Many changes have no
gain but make the language clearer or cleaner. It is not an objective
change but it does help to cleanup the language.
I will not die if we still support old things for the
Hello Stanislav,
I must be having a headache here. But there seriously seems to be a
misunderstanding.
We definitively introduced __construct as a bug fix in our language design.
And that is that you can have a function a in your class b that suddenly
becomes a constructor in the derived class
Stanislav Malyshev wrote:
Hi!
How can it break existing code? It's only on issue if a class is part
of a namespace, and existing code doesn't have namespaces. So it
*can't* be
But existing code can be converted to use namespaces. And the design is
explicitly made so that it would be easy
Another idea: In case xdebug overwrites zend_execute() it can set
EG(return_value_ptr_ptr) to point to some local variable then call
original executor and then print pass return_value to caller or destroy
it dependent on previous value of EG(return_value_ptr_ptr).
Thanks. Dmitry.
Derick
On Thu, 17 Apr 2008, Dmitry Stogov wrote:
Another idea: In case xdebug overwrites zend_execute() it can set
EG(return_value_ptr_ptr) to point to some local variable then call original
executor and then print pass return_value to caller or destroy it dependent on
previous value of
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
Sorry, but I think mainly about PHP performance, and of course I didn't know
that you trace return_values it in xdebug.
After the patch, in case if return value is not used we set
EG(return_value_ptr_ptr) to NULL before call to nested execute().
I
On Fri, 11 Apr 2008, Dmitry Stogov wrote:
dmitryFri Apr 11 09:43:31 2008 UTC
Modified files: (Branch: PHP_5_3)
/php-src NEWS
/ZendEngine2 zend.c zend_execute_API.c zend_vm_def.h
zend_vm_execute.h
Log:
Optimized
Hi Derick,
Sorry, but I think mainly about PHP performance, and of course I didn't
know that you trace return_values it in xdebug.
After the patch, in case if return value is not used we set
EG(return_value_ptr_ptr) to NULL before call to nested execute().
I assume you can just check for
Sorry for dealy.
It must be fixed now.
Thanks. Dmitry.
-Original Message-
From: Steph Fox [mailto:[EMAIL PROTECTED]
Sent: Monday, March 10, 2008 7:26 PM
To: Dmitry Stogov
Cc: internals
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
zend_API.c zend_builtin_functions.c
Thanks Dmitry!
- Original Message -
From: Dmitry Stogov [EMAIL PROTECTED]
To: Steph Fox [EMAIL PROTECTED]
Cc: internals internals@lists.php.net
Sent: Wednesday, March 12, 2008 8:54 AM
Subject: [PHP-DEV] RE: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3) /
zend_API.c
Hi Dmitry,
I finally got around to upgrading my compiler over the weekend, but I still
have to fiddle with line 229 of zend_execute.h to get sane nmake output in
the 5_3 branch. And I'm not alone - see
http://snaps.php.net/win32/snapshot-5.3.log, now it's back up. The only
place it doesn't
Steph Fox wrote:
Hi Dmitry,
I finally got around to upgrading my compiler over the weekend, but I
still have to fiddle with line 229 of zend_execute.h to get sane nmake
output in the 5_3 branch. And I'm not alone - see
http://snaps.php.net/win32/snapshot-5.3.log, now it's back up. The only
On Tue, 12 Feb 2008, Andi Gutmans wrote:
It's really hard to remember this stuff.
Maybe we should make the system actually validate the messages when they
are committed and reject the commit when tags are missing. For commits
where a certain tag isn't relevant we could have an explicit way to
I would really really really really appreciate if the [DOC] tag was used more.
While only random new features (or whatever requiring docs) are tagged
with [DOC] it is totally useless as the doc team still has to browse
through every single commit to figure out if there is something in it
to
it's in the back (and front) of
people's mind :)
Andi
-Original Message-
From: Jani Taskinen [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 12, 2008 10:31 AM
To: Hannes Magnusson
Cc: PHP Development
Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_3
On Feb 12, 2008 7:47 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
On Feb 12, 2008 7:35 PM, Pierre Joye [EMAIL PROTECTED] wrote:
On Feb 12, 2008 7:31 PM, Jani Taskinen [EMAIL PROTECTED] wrote:
I myself have forgot to use the damn dog tag many times. (Which is it
again, @DOC@ or [DOC] ?
On Feb 12, 2008 7:35 PM, Pierre Joye [EMAIL PROTECTED] wrote:
On Feb 12, 2008 7:31 PM, Jani Taskinen [EMAIL PROTECTED] wrote:
I myself have forgot to use the damn dog tag many times. (Which is it
again, @DOC@ or [DOC] ? :) And if I forget, I'd like to be reminded.
Same here, I always
Please, when you give such feedback, please point finger at the persons
who deserve it. Now it feels like everyone is misbehaving here.
Not only mention the name in the body of the email but Cc: the mail to
these people. Each and everyone who deserves to get spanked. And I'm not
joking..
I myself
On Feb 12, 2008 7:31 PM, Jani Taskinen [EMAIL PROTECTED] wrote:
Please, when you give such feedback, please point finger at the persons
who deserve it. Now it feels like everyone is misbehaving here.
Not only mention the name in the body of the email but Cc: the mail to
these people. Each and
Hi Marcus,
It's not a real problem to break the win32 build because it's a very simple
fix, but it'd still be kinda nice if the PHP_5_3 checkout would just build
without manual assistance. Snaps would work an' everything.
Please fix last_scope declaration, mini-patch attached.
- Steph
On Mon, 19 Nov 2007, Dmitry Stogov wrote:
Do you really like to slowdown compilation to support some buggy
extension? zend_extension_op_array_ctor_handler(s) must be used to
setup reserved data.
I don't see why allocated memory shouldn't be properly initialized in
the first place. To me
I don't see why allocated memory shouldn't be properly initialized in
the first place. To me this looked like a bug in the engine because all
I'd guess for the same reason all C allocators don't initialize memory
unless explicitly asked to - because it costs performance.
Secondly, if the
Sorry for the top posting Derick. :)
Stas, this patch solves the problems with @ and doing
php_admin_value error_reporting some value:
http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch
I renamed zend_alter_ini_entry() to zend_alter_ini_entry_ex() and added
one more parameter to
-Original Message-
From: Jani Taskinen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 05, 2007 2:06 PM
To: Stanislav Malyshev
Cc: internals@lists.php.net
Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_ini.c
Sorry for the top posting Derick. :)
Stas, this patch
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 5, 2007, at 08:06:20, Jani Taskinen wrote:
Sorry for the top posting Derick. :)
Stas, this patch solves the problems with @ and doing
php_admin_value error_reporting some value:
http://pecl.php.net/~jani/patches/zend_alter_ini_entry.patch
See the 2nd last comment (by [EMAIL PROTECTED]):
http://bugs.php.net/bug.php?id=41561
The handling of the @ operator is the issue here. Shouldn't that be
turned on/off without touching the INI stuff anyway? (I mailed about
this earlier too, nobody bothered to reply..)
--Jani
On Fri, 2007-08-31
revert might
too...)
johannes
Andi
-Original Message-
From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 12:31 AM
To: Stas Malyshev
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2
On 8/14/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
feature is good to us, it's
Hannes Magnusson wrote:
On 8/14/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
feature
you... And the patch will go in
right after 5.2.4.
Andi
-Original Message-
From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 14, 2007 12:31 AM
To: Stas Malyshev
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2
-DEV] Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2(PHP_5_2)
/ zend_language_parser.y
On 8/14/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the
case
Was there something wrong with the patch or what?
Reverting without _discussing_ is not very nice..
--Jani
Stanislav Malyshev kirjoitti:
stasMon Aug 13 21:16:57 2007 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_language_parser.y
Log:
Revert
Was there something wrong with the patch or what?
Yes, it was major syntax change in minor version. These belong to
5.3/HEAD, as many others of like nature do.
Reverting without _discussing_ is not very nice..
It was discussed and I also confirmed it with the release manager (Ilia).
--
Jani,
Dmitry asked that the patch be reverted and I agreed with him. Since
the author didn't have time (I am guessing), I've asked Stas to
revert the patch. The reason being that this change is too major to
commit at the very last minute in the release cycle. The code will go
back into
Then this needs to be clear in the NEWS file as this is in RC1...
-Hannes
On 8/14/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote:
Jani,
Dmitry asked that the patch be reverted and I agreed with him. Since
the author didn't have time (I am guessing), I've asked Stas to
revert the patch. The
On 8/13/07, Stanislav Malyshev [EMAIL PROTECTED] wrote:
Was there something wrong with the patch or what?
Yes, it was major syntax change in minor version.
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
A Major bugfix maybe ( yes, it was clearly a bug/misfeature)
A bug is when code doesn't do what was intended. This is not the case,
this is the case of missing feature. While I think everybody agrees this
feature is good to us, it's not the time to add it. We lived for years
without it, we
Stanislav Malyshev schrieb:
stas Thu Aug 2 23:57:21 2007 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_ini.h
Log:
add stage for .htacces
This change is great.
However are there any plans to add a symbol or something else so that a
PHP
I see that this feature will be backported to older PHP 5 and even to
PHP 4 used by linux/bsd distributions, because it is a required security
BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release
planned soon AFAIK I want to hold for a bit to see if 5.2 testing
produces any
However are there any plans to add a symbol or something else so that a
PHP extension can detect the support for this feature at runtime?
Hmm... I'm not sure how to do it best for the extension. I checked core
extensions and they don't use INI stages in a way that this change can
break them,
On Fri, 3 Aug 2007, Stanislav Malyshev wrote:
I see that this feature will be backported to older PHP 5 and even to
PHP 4 used by linux/bsd distributions, because it is a required security
BTW: I plan to merge it in 4.4 tree, but since there's no 4.4 release planned
soon AFAIK I want to
Hello,
new stage won't ever work, of course. If there's an extension which
uses INI_STAGE_ACTIVATE and needs to support new htaccess stage, it
can be fixed in source so check for this stage too - but I didn't see
such extensions yet.
Well I actually know such an extension ;) It is called
Hi Antony,
Would this change also apply to string_compare_function and
string_locale_compare_function? They currently use
zend_make_printable_zval()...
Matt
- Original Message -
From: Antony Dovgal
Sent: Thursday, May 17, 2007
tony2001 Thu May 17 17:28:12 2007 UTC
Modified
Sara Golemon [EMAIL PROTECTED] ??:[EMAIL PROTECTED]
The primary reason I went this route rather than handling it in the parser
(I did consider it), was so that a clearer error message could be given
than Unexpected T_STRING. If you'd rather, I'd be happy to move this
fix over there...
Derick Rethans wrote:
derick Fri Nov 10 12:02:51 2006 UTC
Modified files: (Branch: PHP_5_2)
/ZendEngine2 zend_language_scanner.l
Log:
- Forward port the binary cast, which will do the same as the string cast in
PHP 5.2.
What this is supposed to do in
Hi Dmitry!
(moved to internal@)
On 11/8/06, Dmitry Stogov [EMAIL PROTECTED] wrote:
Hi,
Please pay attention to this patch.
It makes overloaded arrays behave in exactly the same way as overloaded
objects.
It disables indirect modification of overloaded arrays and emits notices.
It doesn't
Alshanetsky
Subject: [PHP-DEV] Re: [ZEND-ENGINE-CVS] cvs:
ZendEngine2(PHP_5_2) / zend_object_handlers.c /tests
bug39297.phpt php-src NEWS
Hi Dmitry!
(moved to internal@)
On 11/8/06, Dmitry Stogov [EMAIL PROTECTED] wrote:
Hi,
Please pay attention to this patch.
It makes overloaded arrays
On Mon, October 23, 2006 3:43 pm, Ilia Alshanetsky wrote:
On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
Some ISPs will be quicker to upgrade LAMP than to let users build
SSH
tunnels.
If your ISP does not give you SSH, perhaps it is time to find
yourself another ISP.
I agree with you
On Fri, October 20, 2006 9:35 am, Ilia Alshanetsky wrote:
On 20-Oct-06, at 10:29 AM, Edin Kadribasic wrote:
Known OO conventions - how Java people do it
Its supposed to work that way - it works like that in Java
...
Java is just a single OO language out of many, http://
On Fri, October 20, 2006 9:26 am, Ilia Alshanetsky wrote:
On 20-Oct-06, at 10:24 AM, Lukas Kahwe Smith wrote:
Ilia Alshanetsky wrote:
its funny that ext/mysql is supposed to stay around for BC
reasons even in PHP6, yet it has known unsolvable security issues.
Such as?
for example, it
On 23-Oct-06, at 4:16 PM, Richard Lynch wrote:
Some ISPs will be quicker to upgrade LAMP than to let users build SSH
tunnels.
If your ISP does not give you SSH, perhaps it is time to find
yourself another ISP.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To
Hello William,
Saturday, October 21, 2006, 1:04:44 AM, you wrote:
Ilia Alshanetsky wrote:
On 20-Oct-06, at 5:10 PM, Marcus Boerger wrote:
Hello Ilia,
also an ISO/shared server will never be securewhatever you do and
you can
make MySQL disaalow external connections. That basically
Marcus Boerger wrote:
That said I can only repeat here what I said earlier on IRC. Lets do things
right and make the more complex OO rules as E_STRICT and create new severity
level E_DEPRECATED. E_STRICT will then only be used for 'pedantic' OO rules
while E_DEPRECATED will be used for stuff
Adding more error modes is fine and dandy, but it has to be with a
good reason in mind. In my mind if we add E_DEPRECATED and mark
certain behavior as deprecated it means in a certain version, PHP6
(for example) it will go away and no longer work. Marking something
as deprecated with no
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT as originally stated was
Gregory Beaver wrote:
Hi Ilia and everyone,
E_DEPRECATED makes good sense - it can be a big warning flag that
something will be removed, and will make it very easy to code around
changes. Once something is E_DEPRECATED, however, it must stay that
way, I agree with Ilia.
The point of E_STRICT
Seems like I missed that whole thread.
I don't quite understand what we have to gain from dissallowing overriding
static methods and/or abstract static methods. It's not really in the PHP
spirit.
Making it E_STRICT doesn't solve the situation because it will tell people
it's not an ok thing to do,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
The reason 'abstract static' makes no sense is because static methods
are bound to the class they are defined in. Inheritance rules do not apply.
Therefore a static method that is defined abstract would theoretically
never be able to be
Andi Gutmans wrote:
Seems like I missed that whole thread.
I don't quite understand what we have to gain from dissallowing overriding
static methods and/or abstract static methods. It's not really in the PHP
spirit.
Making it E_STRICT doesn't solve the situation because it will tell people
Edin Kadribasic wrote:
I'm sure there are more examples of how PHP 5.2 and newer will enforce a
different spirit that smells more off a static programming language.
and these changes are being made in a minor release!
its funny that ext/mysql is supposed to stay around for BC reasons even
On 20-Oct-06, at 4:58 AM, Lukas Kahwe Smith wrote:
Edin Kadribasic wrote:
I'm sure there are more examples of how PHP 5.2 and newer will
enforce a
different spirit that smells more off a static programming
language.
and these changes are being made in a minor release!
Minor releases
Ilia Alshanetsky wrote:
its funny that ext/mysql is supposed to stay around for BC reasons
even in PHP6, yet it has known unsolvable security issues.
Such as?
for example, it does not support the new more secure authentication
protocol.
regards,
Lukas
--
PHP Internals - PHP Runtime
1 - 100 of 391 matches
Mail list logo
