On Wed, 15 Jun 2005, Moriyoshi Koizumi wrote:
> On 2005/06/14, at 21:59, Derick Rethans wrote:
>
> > Hello Moriyoshi,
> >
> > The following test is failing for everybody. This bug occurred after
> > you fixed the bug in report #29493. Can you please have a look at
> > it, and perhaps revert it -
Hi,
A while ago someone on IRC suggested that it might be a good idea to add
"public" to PHP 4.x for forward compatibility. I brought it up again on
IRC yesterday and several prominent members of the php core community
said it would be a good idea to add to the 4.4 branch.
The patch seems to
+1.
The patch is actually a one liner :)
-"var" {
+("var"|"public") {
Ilia
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev wrote:
LS>>I think its a good idea to have, to make it somewhat possible to prepare for
LS>>the PHP5 E_STRICT world, while still developing PHP4 compatible code. I
LS>>could for example see this help increase the PHP5 adoption inside PEAR,
Like, PEAR would drop support for PH
LS>>Currently PEAR.php requires PHP 4.2.
This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And
there's almost no people using it with 4.4 - since 4.4 is not
out. So now you want to go out and tell them "upgrade your hosting to our
brand-new PHP version risking breaking exist
Stanislav Malyshev wrote:
LS>>Currently PEAR.php requires PHP 4.2.
This means there are a lot of people using PEAR with PHP 4.3 and 4.2. And
there's almost no people using it with 4.4 - since 4.4 is not
out. So now you want to go out and tell them "upgrade your hosting to our
brand-new PHP v
LS>>
LS>>A while ago someone on IRC suggested that it might be a good idea to add
LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on IRC
LS>>yesterday and several prominent members of the php core community said it
LS>>would be a good idea to add to the 4.4 branch.
Why it
On Wed, 15 Jun 2005 16:36:38 +0200
[EMAIL PROTECTED] (Lukas Smith) wrote:
> Stanislav Malyshev wrote:
>
> > LS>>I think its a good idea to have, to make it somewhat
> > LS>>possible to prepare for the PHP5 E_STRICT world, while
> > LS>>still developing PHP4 compatible code. I could for example
>
Pierre-Alain Joye wrote:
>>> LS>>I think its a good idea to have, to make it somewhat
>>> LS>>possible to prepare for the PHP5 E_STRICT world, while
>>> LS>>still developing PHP4 compatible code. I could for example
>>> LS>>see this help increase the PHP5 adoption inside PEAR,
>>>
>>> Like, PEAR w
SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can
SM>>not be changed if this app should run in both Versions 4 and 5,
SM>>others, like '= new' and '=& new' can easily be adopt by just removing
SM>>the '&' without getting any NOTICE in any VERSION
Here's something I am mis
Stanislav Malyshev wrote:
> SM>>IMHO is 'var' the only thing that produces NOTICES in PHP 5 what can
> SM>>not be changed if this app should run in both Versions 4 and 5,
> SM>>others, like '= new' and '=& new' can easily be adopt by just removing
> SM>>the '&' without getting any NOTICE in any
SM>>> Here's something I am missing - if you say notices are so much rpoblem,
SM>>> why not remove them?
SM>>
SM>>oh, 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 produces.
--
Stanisla
Stanislav Malyshev wrote:
> LS>>
> LS>>A while ago someone on IRC suggested that it might be a good idea to add
> LS>>"public" to PHP 4.x for forward compatibility. I brought it up again on
> IRC
> LS>>yesterday and several prominent members of the php core community said it
> LS>>would be a good
Personally, I don't think there's a significant benefit to adding support
for public. There are so many differences and new features that the gain of
just being able to change "var" to "public" would be marginal at best.
That said, I don't mind supporting if people think it will help. It's a
t
Andi Gutmans wrote:
> Personally, I don't think there's a significant benefit to adding
> support for public. There are so many differences and new features that
> the gain of just being able to change "var" to "public" would be
> marginal at best.
>
> That said, I don't mind supporting if people
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 "forward compatibilit
Hi Wez,
There seem to be some activity in starting a Catalan translation, but
unless at least one of these guys get an account, and a mailing list and
a cvs module is created, this is not possible to start.
http://marc.theaimsgroup.com/?l=phpdoc&m=111601250906644&w=2
Goba
> Are these requests
On Wed, 2005-06-15 at 13:21, Rasmus Lerdorf wrote:
> Andi Gutmans wrote:
> > Personally, I don't think there's a significant benefit to adding
> > support for public. There are so many differences and new features that
> > the gain of just being able to change "var" to "public" would be
> > margina
Hi
I tried compiling HEAD on OS X. Didn't work (it did a few days ago,
can't exactly remember when) with the following error
/bin/sh /opt/cvs/php5.1/libtool --silent --preserve-dup-deps
--mode=compile gcc -IZend/ -I/opt/cvs/php5.1/Zend/ -DPHP_ATOM_INC
-I/opt/cvs/php5.1/include -I/opt/cvs/php5.1/
No strong reason. It was meant to help people find var's so that they can
be explicit about the access modifiers. This is why it was put in E_STRICT.
It's meant to be more helpful and informational messages, and you shouldn't
run your website in E_STRICT. Maybe the difference here are the
expec
On 15.6.2005 21:07 Uhr, Dmitry Stogov wrote:
> Hi Christian,
>
> I hope I just fixed the problem.
> Please verify me.
Compiles and links now with gcc-4.0.0. Will test 3.3 later (aka
tomorrow) and report, if it doesn't work.
chregu
>
> Thanks. Dmitry.
>
>
>>-Original Message-
>>From
Hi,
Today, while discussing with my teachers and colleagues about PHP vs Java,
I've found a typo in the bench.php file.
In the line 169, you should read:
"return(($n < 2) ? 1 : fibo_r($n - 2) + fibo_r($n - 1));"
Could someone please fix it?
Thanks,
Nuno
P.S.: if anyone has some materi
Hi Christian,
I hope I just fixed the problem.
Please verify me.
Thanks. Dmitry.
> -Original Message-
> From: Christian Stocker [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 15, 2005 10:45 PM
> To: PHPdev
> Subject: [PHP-DEV] HEAD currently doesn't compile on OS X 10.4
>
>
> Hi
>
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, because it was deprecated in favour of the
instanceof operator. But there's
Stanislav Malyshev wrote:
I wonder what was the original purpose of PHP5 emitting warning when
seeing 'var'? What are you basically saying now is "I want PHP4 code that
wouldn't have messages on my class vars if run in PHP5". But I'm sure
there was some idea behind these warnings, not?
There
Will look into it.
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, beca
Lukas Smith wrote:
Stanislav Malyshev wrote:
I wonder what was the original purpose of PHP5 emitting warning when
seeing 'var'? What are you basically saying now is "I want PHP4 code
that wouldn't have messages on my class vars if run in PHP5". But I'm
sure there was some idea behind these wa
Lukas Smith wrote:
> Stanislav Malyshev wrote:
>
>> I wonder what was the original purpose of PHP5 emitting warning when
>> seeing 'var'? What are you basically saying now is "I want PHP4 code
>> that wouldn't have messages on my class vars if run in PHP5". But I'm
>> sure there was some idea behi
Rasmus Lerdorf wrote:
> Lukas Smith wrote:
>
>>Stanislav Malyshev wrote:
>>
>>
>>>I wonder what was the original purpose of PHP5 emitting warning when
>>>seeing 'var'? What are you basically saying now is "I want PHP4 code
>>>that wouldn't have messages on my class vars if run in PHP5". But I'm
>>
http://www.akbkhome.com/blog.php/View/75/removing+that+stupid+is_a
+warning..html
You're not the only one ;)
Regards
Alan
On Wed, 2005-06-15 at 23:15 +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
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
activity today.)
- Patch to allow internal functions to return refer
I use a lot of unserialized objects and realised that destructors do
not get called implicitly for them. Is this the intended behavior ?
Precisions on this would be greatly appreciated, thank you.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
Stanislav Malyshev wrote:
> SM>>> Here's something I am missing - if you say notices are so much rpoblem,
> SM>>> why not remove them?
> SM>>
> SM>>oh, 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
33 matches
Mail list logo
