My main focus is on the Windows environment. I'm not in a position to
make any judgements about non windows platforms. As such, my patches
are to extend the capabilities of the windows precompiled binaries.
Most webservers should be able to map different extensions to
different handlers.
As I've
The supplied patch enhances PHP's .INI from ...
php-%sapi-name%.ini
to ...
php%php-version%-%sapi-module-name%.ini
php%php-major-version%.%php-minor-version%.%php-release-version%-%sapi-module-name%.ini
php%php-major-version%.%php-minor-version%-%sapi-module-name%.ini
php%php-major-version%-%sa
Hi Richard,
- Original Message -
From: "Richard Quadling"
> NOTE: I am NOT able to verify this code as I am not yet able to
> compile PHP. I'm still learning this, so please accept my apologies
> for any syntax errors, bugs. I'm more than willing to fix them! And if
> anyone has used MS
Hi,
The main reason of patch is reducing memory allocation overhead and speedup
memory management.
The patch requires full PHP rebuild including "buildconf".
Now "configure" has no "--disable-zend-memory-manager" option, but it has
"--enable-malloc-mm" instead. It is enabled by default in DEBUG
Ilia Alshanetsky wrote:
Looks good to me, although I'd prefer you returned an associated
array rather then an object.
What for do we have object dereferencing then? As gimmick or buzzword?
$err = error_get_last();
echo $err["message"];
vs.
echo error_get_last()->message;
One can still cas
On 18.07.2006 13:38, Michael Wallner wrote:
Ilia Alshanetsky wrote:
Looks good to me, although I'd prefer you returned an associated
array rather then an object.
What for do we have object dereferencing then? As gimmick or buzzword?
Definitely not for returning errors.
Array perfectly fits h
On Sat, 15 Jul 2006, Lukas Smith wrote:
> Ilia Alshanetsky wrote:
> > It's been quite sometime since 5.2 was branched and looking over our "todo"
> > majority of planned changes were made. Therefor I'd like to make an RC1 on
> > Thursday next week and start the stabilization cycle of 5.2, so we ca
On Tue, 18 Jul 2006 14:39:18 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Sat, 15 Jul 2006, Lukas Smith wrote:
>
> > Ilia Alshanetsky wrote:
> > > It's been quite sometime since 5.2 was branched and looking over
> > > our "todo" majority of planned changes were made. Therefor I'd
>
Hello,
We need a PHP 4 release. We need it now and we will need more and
regular releases in the near future.
It is clear that the current RM is not able to do his job in time and
in coordination with the other developers. See the numerous requests
about php4 releases or informations, they are al
Hi Derick,
This patch breaks PEAR::Date (because it reserves class "Date") and all
applications those use it.
Was this break discussed?
Do we really like it in 5.2?
Thanks. Dmitry.
> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, July 18, 2006 4:38
I think we need to rename it. php_date or _date or something. I don't
really care what the name is, but I think we are too late in the game to
get the 'date' identifier. The other functions enabled are fine and
quite necessary actually. Both timezone_abbreviations_list() and
timezone_identi
On Tue, 18 Jul 2006, Dmitry Stogov wrote:
> This patch breaks PEAR::Date (because it reserves class "Date") and all
> applications those use it.
That was kinda obvious and also the reason why it was not in PHP 5.1 as
we added this class too late.
> Was this break discussed?
Yes, this was discu
Didn't we actually have a Date class for five days in a release once and not
a single bug report out of it?
I think we need to rename it. php_date or _date or something. I don't
really care what the name is, but I think we are too late in the game to
get the 'date' identifier. The other fu
Just because we have objects it does not mean we need to use them all
the time. In this instance IMO it makes absolutely no sense to use an
object, it only creates extra overhead. If you want the patch to be
included in 5.2, please change the function to return an associated
array.
On 18
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1. There have been two names under consideration datetime and
phpdate. Personally I'd prefer datetime, but after doing a quick
search on google that seems l
On Tue, 18 Jul 2006 07:23:41 -0700
[EMAIL PROTECTED] (Rasmus Lerdorf) wrote:
> I think we need to rename it. php_date or _date or something. I
> don't really care what the name is, but I think we are too late in
> the game to get the 'date' identifier. The other functions enabled
> are fine and
On 18.07.2006 17:23, Rasmus Lerdorf wrote:
I think we need to rename it. php_date or _date or something. I don't
really care what the name is, but I think we are too late in the game to
get the 'date' identifier. The other functions enabled are fine and
quite necessary actually. Both timezo
Rasmus Lerdorf wrote:
I think we need to rename it. php_date or _date or something. I don't
really care what the name is, but I think we are too late in the game to
get the 'date' identifier. The other functions enabled are fine and
quite necessary actually. Both timezone_abbreviations_list
Lukas Smith wrote:
Rasmus Lerdorf wrote:
I think we need to rename it. php_date or _date or something. I
don't really care what the name is, but I think we are too late in the
game to get the 'date' identifier. The other functions enabled are
fine and quite necessary actually. Both timezon
On Tue, 18 Jul 2006, Rasmus Lerdorf wrote:
> I think we need to rename it. php_date or _date or something. I don't really
> care what the name is, but I think we are too late in the game to get the
> 'date' identifier.
I think this might be one of the bigger mistakes that we can do now. And
I
Lukas,
Ideally all libraries, be it PEAR or otherwise should always prefix
their class and function names, the one obvious prefix would be the
name of the library itself. For example when it comes to PEAR having
a pear_ (for functions) and PEAR (for classes) prefix would be perfect.
When
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.
Wait, you are suggesting to enable this empty class and rename it? And
then he will rename it again f
Hello,
On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Rasmus Lerdorf wrote:
This might also be something that might pop up more in the future so I
think we should figure that out first what we want,
What we should figure out is how to prevent you to pop in with y
On 18-Jul-06, at 12:16 PM, Pierre wrote:
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.
Wait, you are suggesting to enable this empty class and r
On Tuesday 18 July 2006 09:27, Ilia Alshanetsky wrote:
> The date extension functionality can be enabled, but we need to
> rename the date class to avoid naming conflicts encountered with PHP
> 5.1. There have been two names under consideration datetime and
> phpdate. Personally I'd prefer datetime
On 18-Jul-06, at 12:16 PM, Pierre wrote:
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
The date extension functionality can be enabled, but we need to
rename the date class to avoid naming conflicts encountered with PHP
5.1.
Wait, you are suggesting to enable this empty class and re
On 18.07.2006 20:03, Matt Sicker wrote:
It'd be nice to have a php namespace, wouldn't it? ;)
And that would help... how?
Two classes named "Date" will still clash, namespaces won't magically solve it.
Maybe you might not want to include that class until PHP6. Or, how
about for backwards com
Dmitry, can you put this info into a README file or something?
On Jul 18, 2006, at 2:23 AM, Dmitry Stogov wrote:
Hi,
The main reason of patch is reducing memory allocation overhead and
speedup
memory management.
The patch requires full PHP rebuild including "buildconf".
Now "configure" has
Derick Rethans wrote:
Yes, this was discussed in December last year. The PEAR team was plenty
aware of this issue as well and had enough time to address it (about 7
months now).
Derick makes it sound that this was agreed. Sure there was a discussion.
Its an outright lie to suggest that any
No kidding, Derick. Go back and read all those discussions. If we want
to enable the ext/date classes, they need to be prefixed.
-Andrei
On Jul 18, 2006, at 7:16 AM, Dmitry Stogov wrote:
Hi Derick,
This patch breaks PEAR::Date (because it reserves class "Date") and all
applications those us
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Yes, as we finally need the date support that has been ready for 8 months
now. Waiting any longer doesn't make sense either.
We do not need to break gazzillions of applications out there.
What gazzillions of applications are g
On Tue, 18 Jul 2006, Matt Sicker wrote:
> Maybe you might not want to include that class until PHP6. Or, how
> about for backwards compatibility, you do prefix the class name with
> PHP, but when namespaces come into play, using the php namespace
> effectively removes the PHP prefix (e.g. PHPD
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
Yes, as we finally need the date support that has been ready for 8
months now. Waiting any longer doesn't make sense either.
We do not
I am considering changing the required arg storage type for 't' and 'T'
specifiers from void* to zstr*, since they can return either char* or
UChar* and the zstr union encapsulates both. Thoughts on this?
-Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: ht
Derick Rethans wrote:
On Tue, 18 Jul 2006, Steph Fox wrote:
AFAICR the reason it was taken off the public TODO was purely to prevent WW4
breaking out on the spot. I expect Derick (and probably Ilia) had similar
feelings about it now.
Not at all. I don't mind a *civilized* discussion about i
Go for it.
On Jul 18, 2006, at 6:32 AM, Pierre wrote:
Hello,
We need a PHP 4 release. We need it now and we will need more and
regular releases in the near future.
It is clear that the current RM is not able to do his job in time and
in coordination with the other developers. See the numerous
Rob,
I have not tested the patch, but it looks good to me on cursory
overview. I assume it passes your tests?
The only comment I have is regarding the usage of 't' and 'T'
specifiers. Since you always have to pass binary UTF-8 strings to
libxml, we should always use 's' specifier and let PHP d
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
Andreas Korthaus wanted to know about the fate of issues past; the date
extension's o
Steph, we discussed it to death already. Please be realistic.
-Andrei
On Jul 18, 2006, at 10:25 AM, Steph Fox wrote:
No kidding, Derick. Go back and read all those discussions. If we
want to enable the ext/date classes, they need to be prefixed.
Go back and read Ilia's blog entry on the sub
AFAICR the reason it was taken off the public TODO was purely to prevent
WW4
breaking out on the spot. I expect Derick (and probably Ilia) had similar
feelings about it now.
Not at all. I don't mind a *civilized* discussion about it.
You need to be civilized in the first place for such a deb
Steph, we discussed it to death already. Please be realistic.
'Discussed to death', I'd say. There wasn't a decision made, either way, and
I for one don't see why PEAR should dictate terms to PHP.
- Steph
-Andrei
On Jul 18, 2006, at 10:25 AM, Steph Fox wrote:
No kidding, Derick. Go back a
Steph Fox wrote:
Steph Fox wrote:
Do we really like it in 5.2?
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
So your statemetn from above is false. It has never been on PHP
Steph Fox wrote:
Please, Edin, it doesn't behove you to start name-calling.
Listen, I *am* pissed off. If everyone thought "this is going to raise
some resistance on the internals so lets screw them morons and just go
ahead and commit stuff because we're smarter than them" how far would
PH
It was originally on the 5_2 TODO.
Where? Never seen it. Heard Derick lie to people about it a few times.
http://www.zend.com/zend/week/week287.php#Heading2
So your statemetn from above is false. It has never been on PHP 5.2 TODO.
Zend weeklies are something completely different, wouldn't
No kidding, Derick. Go back and read all those discussions. If we want to
enable the ext/date classes, they need to be prefixed.
Go back and read Ilia's blog entry on the subject. There were NO bug reports
about it, in the 5 days the Date class was 'out there'. Does that sound to
you like gaz
Steph Fox wrote:
It was originally on the 5_2 TODO.
^^^
Read it. Understand that this is false.
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Do you have time/inclination to be RM for 4.4? If not, let Pierre do it.
On Jul 18, 2006, at 10:50 AM, Derick Rethans wrote:
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
Go for it.
Que?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals -
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
> Do you have time/inclination to be RM for 4.4? If not, let Pierre do it.
Sure, why wouldn't I? I did an RC before my holiday and soon it's time
for a release... can't do releases in some remote village on Iceland now
can I?
Derick
--
Derick Retha
On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
> Do you have time/inclination to be RM for 4.4? If not, let Pierre do it.
Sure, why wouldn't I? I did an RC before my holiday and soon it's time
for a release... can't do releases in some remote v
Steph Fox wrote:
What gazzillions of applications are going to get broken? Can you name
one outside PEAR?
I'm sure everyone realizes this, but it's not just PEAR, it's any
application that uses the Date class. The Date class can be renamed, but
that won't automatically fix everyone who uses th
On Tue, 18 Jul 2006, Steph Fox wrote:
> AFAICR the reason it was taken off the public TODO was purely to prevent WW4
> breaking out on the spot. I expect Derick (and probably Ilia) had similar
> feelings about it now.
Not at all. I don't mind a *civilized* discussion about it.
Derick
--
PHP In
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
> Go for it.
Que?
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I think we've really reached an unhealthy situation in PHP release
management. We used to shift around this responsibility quite frequently.
Sometimes people would assume responsibility even for a mini release.
When people thought (and rightfully so) that I was a bit too busy to run the
PHP 5.1 re
On Tue, 18 Jul 2006, Steph Fox wrote:
> > Steph Fox wrote:
> > > What gazzillions of applications are going to get broken? Can you name one
> > > outside PEAR?
> > I'm sure everyone realizes this, but it's not just PEAR, it's any
> > application that uses the Date class. The Date class can be rena
Derick Rethans wrote:
Because PEAR doesn't really work with PHP 5 ;-) (a joke people). But
seriously there can be conflicts here, and you can't really disprove
that with 5 days of a .0 release...However I do think that "gazillions"
is a bit of an overstatement.
Sure. FYU it was meant as "man
Steph Fox wrote:
What gazzillions of applications are going to get broken? Can you name
one outside PEAR?
I'm sure everyone realizes this, but it's not just PEAR, it's any
application that uses the Date class. The Date class can be renamed, but
that won't automatically fix everyone who uses the
Aaron, I'm going to repeat it again: in the 5.1.0 release, where the Date
class existed in PHP, after 5 days there were NO bug reports. None, nix,
nada.
Because PEAR doesn't really work with PHP 5 ;-) (a joke people).
That may be a joke, but it's wholly possible that the PHP 5 using community
Because PEAR doesn't really work with PHP 5 ;-) (a joke people). But
seriously there can be conflicts here, and you can't really disprove that
with 5 days of a .0 release...However I do think that "gazillions" is a
bit of an overstatement.
Sure. FYU it was meant as "many applications".
But br
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
> But breaking even a few or "both" is still reckless, irresposible
> behaviour when all that is needed to fix the breakage is rename the
> class. Espacially because of all the bad publicity we get for breaking
> backwards compatibility f
Hey,
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
We are just at the beginning of this stage in PHP's evolution, and I think
we need to agree on a standard that Date and other following classes will
all adhere to. I
Hello Everyone,
With the current version of CVS PHP_5_2 branch I get this compiler
warning:
c:\php\php5_2\zend\zend.c(565) : warning C4700: local variable 'tsrm_ls'
used without having been initialized
- Frank
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
Although we already have quite a few classes in PHP I think we are still
at
an early point and we should make the right decision now. I'd prefer that
from now on going forward we prefix all new classes with Php. In PHP 6,
once
we implement namespaces for classes (yep, on my todo) then we can put
On 7/18/06, John Coggeshall <[EMAIL PROTECTED]> wrote:
On Tue, 2006-07-18 at 20:25 +0200, Edin Kadribasic wrote:
> But breaking even a few or "both" is still reckless, irresposible
> behaviour when all that is needed to fix the breakage is rename the
> class. Espacially because of all the bad pub
Steph Fox wrote:
Yep, that's a fair point. But at the same time, PEAR should be
namespacing their classes - and in fact the date class in PEAR is
breaking PEAR's own coding standards in that respect. Why should classes
Steph stay on topic. Date follows current PEAR naming standards just
fin
Hi Lukas,
Yep, that's a fair point. But at the same time, PEAR should be
namespacing their classes - and in fact the date class in PEAR is
breaking PEAR's own coding standards in that respect. Why should classes
Steph stay on topic. Date follows current PEAR naming standards just fine
and it
PHP 6 will come with some big changes. We could have a compat flag that
supports old-style classes PhpDate if needed.
In any case, it's premature as we don't have this yet and it's not relevant
to PHP 5. I just wanted to Fyi that it's something to consider.
Andi
> -Original Message-
> Fr
On Tue, 18 Jul 2006, Pierre wrote:
On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Andrei Zmievski wrote:
> Do you have time/inclination to be RM for 4.4? If not, let Pierre do it.
Sure, why wouldn't I? I did an RC before my holiday and soon it's time
for a release.
I agree completely.
Zeev
At 21:13 18/07/2006, Andi Gutmans wrote:
I think we've really reached an unhealthy situation in PHP release
management. We used to shift around this responsibility quite frequently.
Sometimes people would assume responsibility even for a mini release.
When people thoug
And last but not least, I fully agree with Andi and you, the needs of
classes internally is growing, faster than ever before. We have to
define rules or conventions.
Up until now extensions have been allowed to use their own name to prefix
functions within them and as classnames, and that kind
Hello,
On 7/18/06, Jani Taskinen <[EMAIL PROTECTED]> wrote:
On Tue, 18 Jul 2006, Pierre wrote:
> On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>> On Tue, 18 Jul 2006, Andrei Zmievski wrote:
>>
>> > Do you have time/inclination to be RM for 4.4? If not, let Pierre do it.
>>
>> Sure, why
Hello,
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
If PHP 6 is going to introduce class namespaces it's pretty much a temporary
problem, no? Again, I have the feeling I'm missing something.
Yes, Lukas coment, you completelly miss it. But that's not the point
of this discussion.
--
PHP I
On Tue, 18 Jul 2006, Pierre wrote:
Welcome back, good to see that you are still pollite.
I'm like a tiger, can't get rid of my stripes. :)
(bare with me, last 6 weeks in duty has been hell)
p.s. Team work. That's how it should work, shouldn't it?
Yes, and in my book, my team colleg
PHP 6 will come with some big changes. We could have a compat flag that
supports old-style classes PhpDate if needed.
In any case, it's premature as we don't have this yet and it's not
relevant
to PHP 5. I just wanted to Fyi that it's something to consider.
It _is_ relevant to PHP 5, because i
Given that PHP 6 far off target, I think we need to develop a
solution that works now. We've already waited too long given how many
classes were added in-core & extensions since 5.0 was released. Just
like we have a naming convention for functions we need to decide on
one for classes as wel
I don't think prefixing things with PHP makes a lot of sense to me for
something like Date. For starters, it isn't very intuitive. But thinking
more long term why name the class "PHPDate" now only to rename it to
"Date" later when we get a PHP namespace? We're avoiding a BC break
today when adoptio
Hi Pierre,
If PHP 6 is going to introduce class namespaces it's pretty much a
temporary
problem, no? Again, I have the feeling I'm missing something.
Yes, Lukas coment, you completelly miss it. But that's not the point
of this discussion.
Care to elucidate? Far as I'm aware the only comment
Pierre,
Will all due respect, option C is what we did when it came to 5.1,
except instead of 5.3 it was 5.2. Sure, we can delay this
indefinitely, but I for one would like some resolution on the issue.
But if the general consensus is to continue treading water, I guess
we can do that too.
I second Ilia.
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 1:55 PM
To: Pierre
Cc: Andi Gutmans; Steph Fox; Derick Rethans; Edin Kadribasic; Dmitry Stogov;
internals@lists.php.net
Subject: Re: [PHP-DEV] Re: PEAR::Date broke
Hello!
A gcov test run has just been finished on the PHP_5_2 branch.
You can view the make log here: http://gcov.php.net/PHP_5_2/make.log.php
You can watch the test results: http://gcov.php.net/PHP_5_2/run-tests.log.php
And you can watch gcov results: http://gcov.php.net/PHP_5_2/lcov/index.php
On Tue, 2006-07-18 at 22:41 +0200, Pierre wrote:
> Yes, and in my book, my team collegues answer mails, don't ignore
> users question and inform the rest of the team of their plans. If you
> read the archives you will see that none of these points has been
> fullfilled in the past 5 months.
Not to
Hello,
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Option A: DateTime & DateTimeZone
Option B: PHPDate & PHPTimezone
The only sane way:
Option C: Delay to 5.3, warn our users in the 5.2 release notes, use Date
That will be true for Date, File or whatever else we may use (Derick,
All,
Will all due respect, option C is what we did when it came to 5.1, except
instead of 5.3 it was 5.2. Sure, we can delay this indefinitely, but I
for
one would like some resolution on the issue. But if the general consensus
is
to continue treading water, I guess we can do that too...
It
Hello,
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Option A: DateTime & DateTimeZone
Option B: PHPDate & PHPTimezone
The only sane way:
Option C: Delay to 5.3, warn our users in the 5.2 release notes, use Date
If you go with this, Pierre, I'll offer now to maintain a namespaced
On Tue, 2006-07-18 at 22:25 +0200, Pierre wrote:
> - to start using the common names in general without a loud,
> "official" and preemptive
> warning to our users (meaning not from one minor to another)
I think we need people in charge of this specific topic. We're largely
developers after all,
Either of those are good options IMO, although we should make a high-level
decision if we want to do PHP prefix or we defer that to PHP 6.
Andi
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 1:49 PM
To: Andi Gutmans
Cc: 'Ste
As do I.
--Jani
On Tue, 18 Jul 2006, Andi Gutmans wrote:
I second Ilia.
_
From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] On Behalf Of Ilia
Alshanetsky
Sent: Tuesday, July 18, 2006 1:55 PM
To: Pierre
Cc: Andi Gutmans; Steph Fox; Derick Rethans; Edin Kadribasic; Dmitry Stogov;
Hello Andrei,
yep, i think that would be much better :-)
only does it work under windows too?
best regards
marcus
Tuesday, July 18, 2006, 7:35:27 PM, you wrote:
> I am considering changing the required arg storage type for 't' and 'T'
> specifiers from void* to zstr*, since they can retur
On 7/18/06, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
Pierre,
Will all due respect, option C is what we did when it came to 5.1, except
instead of 5.3 it was 5.2. Sure, we can delay this indefinitely, but I for
one would like some resolution on the issue. But if the general consensus is
to co
I haven't heard complaints about zstr from Win32 users, so I guess it
does.
-Andrei
On Jul 18, 2006, at 2:24 PM, Marcus Boerger wrote:
Hello Andrei,
yep, i think that would be much better :-)
only does it work under windows too?
best regards
marcus
Tuesday, July 18, 2006, 7:35:27 PM,
Hello Pierre,
please just hold breath and keep that *** for yourself.
best regards
marcus
Tuesday, July 18, 2006, 6:17:09 PM, you wrote:
> Hello,
> On 7/18/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
>> On Tue, 18 Jul 2006, Rasmus Lerdorf wrote:
>> This might also be something that might p
Andi Gutmans wrote:
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
I couldn't agree more. The main question is who the unprefixed namespace
belongs to. I'd say it's either the core or the application but
certainl
On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
> PHP 6 will come with some big changes. We could have a compat flag that
> supports old-style classes PhpDate if needed.
-100
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
Hello Dmitry,
well PEAR broke it's own rules here and somehow i feel PEAR needs to be
punished because PEAR never respected any PHP decision at all. Well you
might see that i am not a fan of PEAR. Actually i only use the minimum set
that allows me to run horde. Anyway the stone already fell into
John Coggeshall wrote:
On Tue, 2006-07-18 at 22:41 +0200, Pierre wrote:
Yes, and in my book, my team collegues answer mails, don't ignore
users question and inform the rest of the team of their plans. If you
read the archives you will see that none of these points has been
fullfilled in the pas
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
I'm probably being dim here, but how is this going to pan out for BC? Either
now, or when PHP 6 comes along and we (presumably) go from PhpDate to
Php::Date? (What am I missing?)
PHPDate would still exists as an alias for BC. The advantage of
na
I know I only lurk here usually, and this may be a daft idea but if I
don't throw it in the water I'll never know if it can float.
Why not allow classes and functions be overridden? For example, if I
define a function named mysql_query it replaces the existing function
and raises an E_STRICT error
Hello Derick,
well i know you d a lot and had to slow down and have been on vacation.
Yet the vast majority is still using php 4 and we are indeed facing a
lof of security issues and don't do our reputation good if keep taking
long times between mini releases. If now Pierre thinks he can do faster
Hi Olivier,
On 7/18/06, Steph Fox <[EMAIL PROTECTED]> wrote:
I'm probably being dim here, but how is this going to pan out for BC?
Either
now, or when PHP 6 comes along and we (presumably) go from PhpDate to
Php::Date? (What am I missing?)
PHPDate would still exists as an alias for BC. The
On Tue, 2006-07-18 at 16:54 -0400, John Coggeshall wrote:
> On Tue, 2006-07-18 at 13:33 -0700, Andi Gutmans wrote:
> > PHP 6 will come with some big changes. We could have a compat flag that
> > supports old-style classes PhpDate if needed.
>
> -100
>
*-10
Sorry to barge in here with my opinions but isnt this discussion a little
mute?
How many more PHP 4 releases are you expecting? Surely 4.4.3 should be the
last? (Baring any serious security flaws) IMO bug fixes should be reserved
for PHP 5.x releases only.
Regards
Marco
1 - 100 of 189 matches
Mail list logo
