Stanislav Malyshev wrote:
SM Here's something I am missing - if you say notices are so much rpoblem,
SM why not remove them?
SM
SMoh, PHP introduced NOTICEs so that i remove them? great ...
But that's _exactly_ what is proposed - to add a keyword to PHP to
only to remove notices that PHP
Mike Bretz wrote:
Rasmus Lerdorf wrote:
What was the reasoning again for not having var be a synonym for public
in PHP5? It is a bit annoying that a simple PHP4 class using var throws
a notice in PHP5 when there is technically nothing wrong with it.
-Rasmus
I personally don't support
Hi,
Lukas Smith wrote:
I think its a good idea to have, to make it somewhat possible to prepare
for the PHP5 E_STRICT world, while still developing PHP4 compatible
code. I could for example see this help increase the PHP5 adoption
inside PEAR, since this would allow us to make some packages
Lukas Smith wrote:
Sebastian Mendel wrote:
and is it a problem to implement such a new error level also with PHP
4.4. for example reporting overwriting $this is not allowed in PHP 5 ?
and, when we are at this, what about 'clone' as a dummy-keyword in PHP
4.4 ?
err no .. because that
Stephan Schmidt wrote:
Hi,
Lukas Smith wrote:
I think its a good idea to have, to make it somewhat possible to
prepare for the PHP5 E_STRICT world, while still developing PHP4
compatible code. I could for example see this help increase the PHP5
adoption inside PEAR, since this would allow
Hi Sebastian,
On Thursday 16 June 2005 11:16, Sebastian Mendel wrote:
err no .. because that would break existing php 4 code in 4.4
what exactly? the new error-level? the message with this new
error-level? or the dummy-keyword?
sorry but i didnt see this.
That an error, which isn't
On Thursday 16 June 2005 11:27, Sebastian Mendel wrote:
I guess, this will more likely produce an error message like this:
Parse error: syntax error, unexpected T_PUBLIC, expecting T_STRING in
public.php on line 2
right
So I'm strongly against this change. If you want to run PHP4 code
Can no longer compile HEAD. When replacing PHP_ARRAY_CMP_FUNC_VARS in
the 2 static functions with the actual variable definitions it compiles
fine.
/home/rrichards/php5/ext/standard/array.c: In function
`php_array_intersect':
/home/rrichards/php5/ext/standard/array.c:2864: parse error before
Hi!
Dunno, if this is the right place to ask, but I give it a try anyway. If
I'm misguided, please feel free to point me in the right direction!
Attached is a patch which adds a 6th option to openssl_pkcs7_verify,
which should be a string and point to a file where the contents of the
signed
Seems to work...
At 11:15 PM 6/15/2005 +0200, Michael Wallner wrote:
I already complained about that issue several times on IRC
and now that it's time for PHP-5.1 to come, I'll just throw
this question/rant in...
Using is_a() throws a notice (E_STRICT IIRC) in PHP5, which
should be fine,
Hi Andi Gutmans, you wrote:
Seems to work...
Sorry, what seems to work what way?
Thanks,
--
Michael - mike(@)php.net
signature.asc
Description: OpenPGP digital signature
instanceof calls __autoload()
At 04:02 PM 6/16/2005 +0200, Michael Wallner wrote:
Hi Andi Gutmans, you wrote:
Seems to work...
Sorry, what seems to work what way?
Thanks,
--
Michael - mike(@)php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Hi Andi Gutmans, you wrote:
instanceof calls __autoload()
Well, what for I wonder?
If the class is not defined, no object can be an instance of it...
Regards,
--
Michael - mike(@)php.net
signature.asc
Description: OpenPGP digital signature
I just fixed this; it was a trailing ; problem in that macro.
--Wez.
On 6/16/05, Rob Richards [EMAIL PROTECTED] wrote:
Can no longer compile HEAD. When replacing PHP_ARRAY_CMP_FUNC_VARS in
the 2 static functions with the actual variable definitions it compiles
fine.
What's the difference between the data you save and the data that's
read in? In other words, how is this different from copying the file
from one place to another; why would you use it?
--Wez.
On 6/16/05, Marton Kenyeres [EMAIL PROTECTED] wrote:
Hi!
Dunno, if this is the right place to ask,
Thanks. That was it.
Rob
Wez Furlong wrote:
I just fixed this; it was a trailing ; problem in that macro.
--Wez.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Because it's a generic way of fetching classes and there's no reason to
change it.
If there's a real problem then email me.
Andi
At 04:55 PM 6/16/2005 +0200, Michael Wallner wrote:
Hi Andi Gutmans, you wrote:
instanceof calls __autoload()
Well, what for I wonder?
If the class is not
Wez Furlong wrote:
What's the difference between the data you save and the data that's
read in? In other words, how is this different from copying the file
from one place to another; why would you use it?
--Wez.
The data you read in is a signed message (which can be in several
formats),
OK; can you make sure that the patch applies to HEAD, and then attach
it as a text attachment in an email and/or upload it to a www server,
and I'll apply it.
Thanks,
--Wez.
On 6/16/05, Marton Kenyeres [EMAIL PROTECTED] wrote:
Wez Furlong wrote:
What's the difference between the data you
Derick Rethans wrote:
Hello,
after reading this very long thread, and problems with having the public
keyword I decided not to allow any kind of forward compability to be
introduced into PHP 4.4. Discussion is over.
Yeah, I think the change really needs to be in PHP5 instead. Right now
Several of my administrators have grown to love PHPIniDir
in the sapi/apache2handler/, so I've thrown together this
patch for Apache 1.3 mod_php to provide the feature. I'm
guessing alot of users would be grateful for it if they
want to keep php.ini in the conf/ tree, or wherever makes
the most
On Thu, Jun 16, 2005 at 09:30:20AM -0700, boots wrote:
If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think
Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.
I think it can help, and I don't see how it can hurt given the fact it's
not on unless you want it to.
Zeev
At 19:30 16/06/2005, boots wrote:
It seems a bit over-zealous to throw a fatal error when you're writing
code to avoid a fatal error.
If autoload fails, instanceof should simply return false.
--Wez.
On 6/16/05, Andi Gutmans [EMAIL PROTECTED] wrote:
Because it's a generic way of fetching classes and there's no reason to
change
At 18:30 16/06/2005, Rasmus Lerdorf wrote:
Derick Rethans wrote:
Hello,
after reading this very long thread, and problems with having the public
keyword I decided not to allow any kind of forward compability to be
introduced into PHP 4.4. Discussion is over.
Yeah, I think the change really
If there is any merit to E_STRICT as it stands currently I find it to
be negated by the fact that it throws messages for completely
acceptable code that the engine is both willing and capable of
handling. If var is not acceptable, I think it should be removed as a
keyword. If it is
On Thu, 16 Jun 2005, Zeev Suraski wrote:
At 18:30 16/06/2005, Rasmus Lerdorf wrote:
Derick Rethans wrote:
Hello,
after reading this very long thread, and problems with having the public
keyword I decided not to allow any kind of forward compability to be
introduced into PHP 4.4.
Hello Zeev,
though the idea is nice and does what we want here to a certain level it
still doesn't allow to implement ifsetor() or coalesce() or any other flavor
described here as proved by the following snippet:
[EMAIL PROTECTED] ~ $ php -r 'function ifsetor($a, $def=false) { return
Hello Sebastian,
how does this allow you to check for subscriptions?
Are you going to write a subscription walker? Wouldn't that be the
opposite of fast?
marcus
Tuesday, June 14, 2005, 3:45:33 PM, you wrote:
Robert Cummings wrote:
[...]
On that note, how comes there's a $GLOBAL array
Marcus,
If you read what I said in my emails on this topic, it's clear that I know
that this is the case. As I said, this approach has the side effect of
creating an empty placeholder if the variable to be checked doesn't
exist. I also said that I think it would usually make more sense to
Hello Zeev,
Thursday, June 16, 2005, 7:12:49 PM, you wrote:
Marcus,
If you read what I said in my emails on this topic, it's clear that I know
that this is the case. As I said, this approach has the side effect of
creating an empty placeholder if the variable to be checked doesn't
Hello Andi,
Thursday, June 16, 2005, 3:08:18 AM, you wrote:
Hi,
Just to give a status update on PHP 5.1 Beta 2:
- PDO Fix (Wez has already given me the green light to go ahead).
I'm waiting to finalize the following:
- Date changes (Waiting for green light from Derick. I still saw some
At 20:16 16/06/2005, Marcus Boerger wrote:
Hello Zeev,
Thursday, June 16, 2005, 7:12:49 PM, you wrote:
Marcus,
If you read what I said in my emails on this topic, it's clear that I know
that this is the case. As I said, this approach has the side effect of
creating an empty placeholder
On Thu, 2005-06-16 at 12:51, Zeev Suraski wrote:
Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.
I think it can help, and I don't see how it can hurt given the fact it's
not on unless you
On 6/16/05, Zeev Suraski [EMAIL PROTECTED] wrote:
Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.
Well, that depends on your definition of default;
php.ini-recommended in HEAD shows:
; - Show
At 20:39 16/06/2005, Dan Scott wrote:
On 6/16/05, Zeev Suraski [EMAIL PROTECTED] wrote:
Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.
Well, that depends on your definition of default;
I
On 6/16/05, Zeev Suraski [EMAIL PROTECTED] wrote:
At 20:39 16/06/2005, Dan Scott wrote:
On 6/16/05, Zeev Suraski [EMAIL PROTECTED] wrote:
Why would you enable it then? You have to very explicitly enable it, as
it's off by default, and doesn't get enabled even if you switch to E_ALL.
You missed the point of E_STRICT. I introduced it as an E_PEDANTIC. That
was the whole idea. To be pedantic about code that works, not to warn about
code that doesn't work (which is for higher warning levels)
At 09:30 AM 6/16/2005 -0700, boots wrote:
I was hoping that in the future, E_STRICT
--- Andi Gutmans [EMAIL PROTECTED] wrote:
You missed the point of E_STRICT. I introduced it as an E_PEDANTIC.
That was the whole idea. To be pedantic about code that works, not
to warn about code that doesn't work (which is for higher warning
levels)
I don't think I missed that, I just
On Jun 16, 2005, at 2:50 PM, boots wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
You missed the point of E_STRICT. I introduced it as an E_PEDANTIC.
That was the whole idea. To be pedantic about code that works, not
to warn about code that doesn't work (which is for higher warning
--- George Schlossnagle [EMAIL PROTECTED] wrote:
On Jun 16, 2005, at 2:50 PM, boots wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
You missed the point of E_STRICT. I introduced it as an
E_PEDANTIC.
That was the whole idea. To be pedantic about code that works,
not
to warn about
Hello boots,
if(AppDevLevel == 'Production')
{
error_reporting(E_ALL);
}
else
{
error_reporting(E_ALL | E_STRICT);
}
Why don't you implement something like this in your application -
then you CAN control what error level is used at the client site.
--
Best regards,
Jason Garber wrote:
Hello boots,
if(AppDevLevel == 'Production')
{
error_reporting(E_ALL);
}
else
{
error_reporting(E_ALL | E_STRICT);
}
Why don't you implement something like this in your application -
then you CAN control what error level is used at the
Hello Rasmus,
Thanks. I guess I did not realize that because all of my
application logic is included after I set error_reporting()
Thanks for pointing this out.
--
Best regards,
Jasonmailto:[EMAIL PROTECTED]
Thursday, June 16, 2005, 4:32:11 PM, you wrote:
On Thu, 16 Jun 2005 23:12:11 -
[EMAIL PROTECTED] (Jani Taskinen) wrote:
sniperThu Jun 16 19:12:11 2005 EDT
Added files:
/php-src/ext/date/lib timelib.m4
Modified files:
/php-src/ext/date config.m4 php_date.c
I suggest you use E_ALL.
At 11:50 AM 6/16/2005 -0700, boots wrote:
--- Andi Gutmans [EMAIL PROTECTED] wrote:
You missed the point of E_STRICT. I introduced it as an E_PEDANTIC.
That was the whole idea. To be pedantic about code that works, not
to warn about code that doesn't work (which is
These answers make me feel as if maybe just a little bit you guys are
looking down your nose at me without really considering the basis of
the issue I am trying to raise. I know the tools well enough to use
E_ALL -- thanks. I'm concerned about end users who don't know enough to
help themselves --
Is there plans to allow ftruncate calls on user defined stream wrappers?
i.e. The wrapper class would implement:
bool stream_truncate(int length);
-justin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Jun 16, 2005, at 10:15 PM, boots wrote:
These answers make me feel as if maybe just a little bit you guys are
looking down your nose at me without really considering the basis of
the issue I am trying to raise. I know the tools well enough to use
E_ALL -- thanks. I'm concerned about end
49 matches
Mail list logo
