From: Antony Dovgal [mailto:[EMAIL PROTECTED]
3. regexp
1. make ereg an extension
2. PCRE extension will not be allowed to be disabled.
3. core of PHP should be made to work with PCRE so that we can
safely disable ereg
4.
Christian Schneider wrote:
I'm with Lukas there about the E_STRICT/E_DEPRECATED split but I'm not
Feel like working up a patch for 5.3 for this? :)
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yes, PHP-GTK. :)
I don't know much of the GTK, let alone PHP-GTK. What PHP-GTK stores in
static arrays?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Yes, PHP-GTK. :)
-Andrei
On Apr 16, 2007, at 11:36 AM, Stanislav Malyshev wrote:
Sorry for the cryptic reply. I think that initializing a static
class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an
Hi,
FYI I have updated the todo list according to the recent discussions:
http://oss.backendmedia.com/index.php?area=PHPTODOpage=PhP60view=diffto=2007-04-17+10%3A47%3A32from=2007-04-12+16%3A32%3A02
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 4/17/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hey,
I have a few more questions:
Other Additions/Changes:
7. add E_STRICT to E_ALL DONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted
On 4/17/07, Christian Schneider [EMAIL PROTECTED] wrote:
Hannes Magnusson wrote:
7. add E_STRICT to E_ALL DONE (dmitry)
My dictionary says that all means *all*, not all except this and
this and sometimes not that.
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this
Hey,
I have a few more questions:
Other Additions/Changes:
7. add E_STRICT to E_ALL DONE (dmitry)
Currently the plan is to split E_STRICT into E_STRICT and E_DEPRECATED
in PHP 5.3. Once we do that I think this change should be adjusted to
only include E_DEPRECATED in E_ALL and not E_STRICT.
On 17/04/07, Hannes Magnusson [EMAIL PROTECTED] wrote:
On 4/17/07, Christian Schneider [EMAIL PROTECTED] wrote:
Hannes Magnusson wrote:
7. add E_STRICT to E_ALL DONE (dmitry)
My dictionary says that all means *all*, not all except this and
this and sometimes not that.
E_ALL should
Hannes Magnusson wrote:
7. add E_STRICT to E_ALL DONE (dmitry)
My dictionary says that all means *all*, not all except this and
this and sometimes not that.
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changing E_ALL to include everything
On 4/17/07, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
Hey,
What is the status regarding reflection and spl. Do we still want to
allow disabling?
Most of its features could (should?) be moved to ZE2 as they are what
can be considered as part of the language. It is even more important
as some
On Tue, April 17, 2007 8:15 am, Hannes Magnusson wrote:
On 4/17/07, Christian Schneider [EMAIL PROTECTED] wrote:
Hannes Magnusson wrote:
7. add E_STRICT to E_ALL DONE (dmitry)
My dictionary says that all means *all*, not all except this
and
this and sometimes not that.
E_ALL should
Stanislav Malyshev wrote:
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. module X
has functionality A
Sorry for the cryptic reply. I think that initializing a static class
property as well as initializing a default property with for example
an array is an obvious use case. Try to do the following in an extension:
class c {
static $prop1 = array(foo, bar);
var $prop2 =
Stanislav Malyshev wrote:
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.
I think to better understand what would be required a use
Initializing a static class resp. default instance variable with f.e.
an array is an obvious use case.
Err, I'm afraid I don't understand neither your abbreviations nor what
the actual use case is. Can you describe real use case - i.e. module X
has functionality A and B, and to make A work
Antony Dovgal wrote:
On 04/12/2007 06:37 PM, Lukas Kahwe Smith wrote:
7. ext/soap
1. ext/soap will be turned on by default
2. implement some of the security extensions to ext/soap
3. watch axis2 based implementation development
I am guessing the security stuff
On Thu, 12 Apr 2007, Lukas Kahwe Smith wrote:
5. move mime_magic from the core to PECL
6. fileinfo
1. move the Fileinfo extension to the core, and enable it by default.
2. Fileinfo extension should be updated to only load its database
once on MINIT.
Didn't we fast
Yes, if we have persistent zvals we can use objects/arrays as
properties or constants for internal classes. I asked for this 2.5
years ago.
-Andrei
On Apr 12, 2007, at 3:57 PM, Stanislav Malyshev wrote:
Well, actually persisting zvals between requests would be very
problematic since it
Yes, if we have persistent zvals we can use objects/arrays as properties
or constants for internal classes. I asked for this 2.5 years ago.
If they are initialized on startup, I think it's doable, though they
shouldn't be directly accessible to the PHP user, since they should be
immutable. So
That can be handled with read_property and write_property handlers.
Disallowing access to PHP users is an artificial restriction that we
should find ways around.
-Andrei
On Apr 13, 2007, at 12:43 PM, Stanislav Malyshev wrote:
Yes, if we have persistent zvals we can use objects/arrays as
That can be handled with read_property and write_property handlers.
Disallowing access to PHP users is an artificial restriction that we
should find ways around.
If you have these handlers, why you need read-made persistent zvals? You
can construct any zval you want once property is read and
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.
-Andrei
On Apr 13, 2007, at 1:03 PM, Stanislav Malyshev wrote:
That can be handled
Fine, let's step back for a bit. What I want to be able to do is have
objects/arrays as internal properties and constants. Can we make that
possible? Last time I looked it required having persistent zvals.
I think to better understand what would be required a use case would
help a lot. Could
Hi,
Going over the todo list I wanted to bring up a few topics once again
for review/discussion (not flaming):
http://oss.backendmedia.com/PhP60
# Unicode
3. remove old parameter parsing API and replace with one that
supports unicode related functionality
I just want to remind that
Hi Lukas,
On Thu, 2007-04-12 at 16:37 +0200, Lukas Kahwe Smith wrote:
4. safe_mode/open_basedir
1. remove safe mode and throw E_CORE_ERROR when set
2. unbundle safe_mode_exec_dir from safe_mode and keep it
(rasmus) (take a look at this patch too)
3. new ini
Hi Lukas,
Lukas Kahwe Smith wrote:
Hi,
Going over the todo list I wanted to bring up a few topics once again
for review/discussion (not flaming):
http://oss.backendmedia.com/PhP60
# Unicode
3. remove old parameter parsing API and replace with one that
supports unicode related
On Thu, 2007-04-12 at 17:52 +0200, Johannes Schlüter wrote:
No.
Dmitry removed it on 2006/03/16 10:33:23 but Zeev reverted that change
on 2006/06/05 13:58:52.
I didn't find the discussion but I remember there was some When did we
decide on that? posting from Zeev.
Ah I'm sorry, reading is
Hello Johannes,
Thursday, April 12, 2007, 5:52:57 PM, you wrote:
Hi Lukas,
On Thu, 2007-04-12 at 16:37 +0200, Lukas Kahwe Smith wrote:
4. safe_mode/open_basedir
1. remove safe mode and throw E_CORE_ERROR when set
2. unbundle safe_mode_exec_dir from safe_mode and
On 04/12/2007 06:37 PM, Lukas Kahwe Smith wrote:
3. remove old parameter parsing API and replace with one that
supports unicode related functionality
I just want to remind that when we made some changes to the parameter
parsing API's last time it created some BC issues (like with
Antony Dovgal wrote:
11. kill % but keep ?.
Sounds easy enough to do. Why not do it know, so that we can hear
about the impact for users as early as possible.
Yeah, I'll post the patch in a minute..
Please leave this alone. There is no advantage to removing it and it
breaks existing
On 04/12/2007 11:38 PM, Edin Kadribasic wrote:
Antony Dovgal wrote:
11. kill % but keep ?.
Sounds easy enough to do. Why not do it know, so that we can hear
about the impact for users as early as possible.
Yeah, I'll post the patch in a minute..
Please leave this alone. There is no
This is more like - ask ZE not to clean what it points to when it is
cleaning up the zval, and of course not to allow userland to change it.
Well, actually persisting zvals between requests would be very
problematic since it can not then use regular memory allocator (which is
cleaned up at
Hi,
I just wanted to ask everybody working on PHP6 to take the time to look
over the PHP6 todo list [1] and note any items that need to be updated.
As always either let me know if you need a login or simply send me what
you think needs changed. I am sure that a few items can probably be
35 matches
Mail list logo
