At 07:55 PM 11/18/2003 -0500, Mike Robinson wrote:
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that we agree on a certain
Just a warning.
I commited your patch. Not sure about the naming but it's the status quo
for now :)
Andi
At 09:20 PM 11/18/2003 -0800, Sara Golemon wrote:
> I added an E_STRICT error level today which purists can use to make sure
> that there scripts are using the latest and greatest suggested me
> I added an E_STRICT error level today which purists can use to make sure
> that there scripts are using the latest and greatest suggested method of
> coding (according to what we decide).
>
Should E_STRICT halt execution (as with E_ERROR) or simply state a warning
(as with E_NOTICE / E_WARNING)?
Ilia Alshanetsky wrote:
> IMHO people will be expecting some functionality breaks if and when
> they upgrade to 5.0, not so when upgrading from 5.0 to 5.1. I believe
> that if we do not make the change now, we'd need to wait for the next
> major functionally altering release to make this change.
Ilia Alshanetsky wrote:
On a related note, since a major PHP version is now being released, perhaps it
is the time to finally remove old deprecated functionality that in many cases
deprecated for years. I propose that we agree on a certain version as a
minimum and remove all deprecated functiona
On November 18, 2003 08:05 pm, Sara Golemon wrote:
> This way cruft is left out of a build by default, but can be easily put
> back in by those who need it. Then with the next version (5.1? / 6.0?) do
> the actual dirty work of taking them out for good. More gentle on the
> scripters.
IMHO peop
> When it comes to removing deprecated functions entirely, I'd favor a
> ./configure option (--enable-deprecated) which would define
> PHP_USE_DEPRECATED. Then those functions could be "removed" with:
>
> #ifdef PHP_USE_DEPRECATED
> .
> .
> .
> #endif
That's pretty much what they do in GTK src.
> On a related note, since a major PHP version is now being released,
perhaps it
> is the time to finally remove old deprecated functionality that in many
cases
> deprecated for years. I propose that we agree on a certain version as a
> minimum and remove all deprecated functionality that was marke
Ilia Alshanetsky wrote:
> On a related note, since a major PHP version is now being
> released, perhaps it is the time to finally remove old
> deprecated functionality that in many cases deprecated for
> years. I propose that we agree on a certain version as a
> minimum and remove all deprecated
On November 18, 2003 07:30 pm, Sara Golemon wrote:
> Is it a good time to dredge up the old topic of making a PHP_DEPALIAS() to
> act like PHP_FALIAS() but throw an E_STRICT error saying that the function
> has been deprecated?
+1
On a related note, since a major PHP version is now being released
> andi Tue Nov 18 04:25:05 2003 EDT
>
> Modified files:
>/ZendEngine2 zend.c zend_builtin_functions.c zend_constants.c
>zend_errors.h zend_language_parser.y
> Log:
> - Add E_STRICT, to be used to warn purists (like Jani :)
>
Is it a good time to dredge up the old topic of mak
On November 18, 2003 05:00 pm, Andi Gutmans wrote:
> If you have any further ideas of stuff which makes sense to add to this
> option let me know. For obvious reasons this will be off by default.
When objects are passed to functions intended for arrays.
Ilia
--
PHP Internals - PHP Runtime Devel
On Wed, 19 Nov 2003, Andi Gutmans wrote:
>Hey,
>
>I added an E_STRICT error level today which purists can use to make sure
>that there scripts are using the latest and greatest suggested method of
>coding (according to what we decide).
>Ideas are things like:
>a) Not using var for member variabl
--- Rob Richards <[EMAIL PROTECTED]> wrote:
> To check the memory, I had _CrtDumpMemoryLeaks() log to a file after
> the tsrm_shutdown to test final leaks. Had to step through the code
> otherwise for other parts as the system would bail out without any
> indication of where. For the patch, the c
Andi Gutmans wrote:
a) Not using var for member variables but moving to PPP.
b) Not using is_a but using instanceof.
c) references usage - things like:
regards,
Wojtek
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Yeah, this is something we need to tackle. i think we're going to have to
keep the pretty case version but it's going to be a slight hit in performance.
Remember if anyone has posted a patch for this in the past? If not I'll try
and look into fixing it tomorrow.
Andi
At 09:42 AM 11/18/2003 -080
Hey,
I added an E_STRICT error level today which purists can use to make sure
that there scripts are using the latest and greatest suggested method of
coding (according to what we decide).
Ideas are things like:
a) Not using var for member variables but moving to PPP.
b) Not using is_a but using
Hey guys n' girls,
Just reminding you that Beta 3 is 12 days off so finish off stuff you want
to have in there.
Andi
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I already work with the french translation team ([EMAIL PROTECTED], [EMAIL PROTECTED],
...) and I'd want a cvs account with the phpdoc-fr karma to commit fixes and changes.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
We run into a problem, when tryng to organize class
files since autoload always uses lowercase.
My class file, for example, is named
ArrayIterator.class.php (as the class ArrayIterator )
but I get the following error when trying to autoload
the class:
Warning:
__autoload(/usr/local/apache2/htdoc
Stig S. Bakken wrote:
> What about putting "SIGSEGV" there instead? :-)
That's actually planned for the PHP-based benchmark executer :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-
From: Zeev Suraski
> Same questions here... The extra calls to ts_free_thread() seem
> bogus. Not sure yet about the other changes although they probably make
> more sense - I never made too much effort to ensure that the cleanup of a
> thread is very complete...
You are correct. The ts_free_th
On Sun, 2003-11-16 at 17:46, Sebastian Bergmann wrote:
> Markus Fischer wrote:
> > first nearly all numbers appear capped at special values (?)
>
> Yes, this is odd. But I don't know the cause of it.
>
> > and second the "Member Access" has no value.
>
> This is because some of the tests wit
I'd like to add the win32std extension.
It contains:
- RES (access to resource of .exe/.dll files on Win32)
- RES stream wrapper for reading. Compatible with the res protocol defined by MS
- REGISTRY access (from Frank M. Kromann)
- Common Win32 dialogs (open/save file, open dir, message boxes)
At 06:06 18/11/2003, Michael Sisolak wrote:
> I have been looking at the IIS isapi issues and came up with the
> following patch:
>
> http://www.ctindustries.net/patches/zts-php5.diff.txt
Rob,
I've done some work in the past on ISAPI threading issues (although I
by no means claim to understand how
Hello, I've been mailing some lists with this issue without any luck. I hope this is
the right place to post this.
I was recently shocked when I discovered the implementation of Sybase "identical
fields".
The PHP manual for sybase_fetch_array() reads:
Note: When selecting fields with identica
Ron,
It was just a temporary problem... no need to create
more work, and certainly no need for new hardware.
--Wez.
From: "Ronald Chmara" <[EMAIL PROTECTED]>
> There are scripts to warn of such things (lack of space). I suggest
> that they be implemented, if feasible, or, if not, a call go out
On Nov 18, 2003, at 4:29 AM, Edin Kadribasic wrote:
Fixed, thanks for noticing.
Edin
On Tuesday, Nov 18, 2003, at 10:12 Europe/Copenhagen, Uwe Schindler
wrote:
Looking into the win32 snapshot logs: A lot of errors during compile
because of no disk space.
Uwe
There are scripts to warn of such thi
Fixed, thanks for noticing.
Edin
On Tuesday, Nov 18, 2003, at 10:12 Europe/Copenhagen, Uwe Schindler
wrote:
Looking into the win32 snapshot logs: A lot of errors during compile
because of no disk space.
Uwe
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlan
Looking into the win32 snapshot logs: A lot of errors during compile
because of no disk space.
Uwe
-
Uwe Schindler
[EMAIL PROTECTED] - http://www.php.net
NSAPI SAPI developer
Erlangen, Germany
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/u
At 08:06 PM 11/17/2003 -0800, Michael Sisolak wrote:
> I have been looking at the IIS isapi issues and came up with the
> following patch:
>
> http://www.ctindustries.net/patches/zts-php5.diff.txt
Rob,
I've done some work in the past on ISAPI threading issues (although I
by no means claim to under
31 matches
Mail list logo
