> 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
> >
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: http://www.php.net/uns
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
exten
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 t
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
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 every
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".
>
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 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 t
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
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
Hi,
FYI I have updated the todo list according to the recent discussions:
http://oss.backendmedia.com/index.php?area=PHPTODO&page=PhP60&view=diff&to=2007-04-17+10%3A47%3A32&from=2007-04-12+16%3A32%3A02
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
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 = array(
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 function
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 wi
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
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
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 y
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 wi
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 y
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
p
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
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 ca
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
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 the
On 04/12/2007 11:38 PM, Edin Kadribasic wrote:
Antony Dovgal wrote:
11. kill "<%" but keep "
Yeah, I'll post the patch in a minute..
Please leave this alone. There is no advantage to removing it
Surely there is, we're removing one more useless feature.
and it breaks existing apps.
I
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 exi
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
array_me
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
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
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 rel
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
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 when
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
marke
35 matches
Mail list logo
