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 do
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 would break existing php 4 c
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 E_
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 .. bec
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 wo
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 P
I completely agree. This (or any other "public-in-4.4" solution) would
only create an extra branch to maintain for both developers and users;
no one can expect all of the PHP 4.x base to go 4.4, and code with
"public" that "supports php 4 and 5" would actually break in 4.<4 and
still would be:
- u
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
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.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
--
PHP Intern
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, becaus
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: http://
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.
>
> /home/rrichards/p
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
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 define
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), that
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 n
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 se
Hello Andi,
they funnily added the ability to specify the compiler 'flavor'.
Meaning you are able to specify how the compiler should treat your code
in terms of c-spcs and compiler additions being used to spcifically
force certain behavior of a certain version. Since we are developing
against C9
I was hoping that in the future, E_STRICT wasn't expanded and was
perhaps even taken back a step. I understand the reason for it: code
correctness. Yet if PHP5 is (rightly) considered a runtime engine then
its job should be to evaluate and execute code and in the case of
failure, explain why it cou
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 thi
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:
I
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
> cha
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 re
> 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 accept
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
> > > introduc
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
isset(
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 a
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 si
At 19:57 16/06/2005, Sara Golemon 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 it should
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
> e
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 som
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 placeholde
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:
; - S
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
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
leve
--- 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
>
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
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:
R
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 (whic
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 -- b
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 user
Nelson Menezes wrote:
> On 6/16/05, Johannes Schlueter <[EMAIL PROTECTED]> wrote:
>> 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
55 matches
Mail list logo
