On Wed, 2003-12-03 at 13:41, Magnus Määttä wrote:
> On Wednesday 03 December 2003 12.59, Derick Rethans wrote:
> > On Wed, 3 Dec 2003, Andi Gutmans wrote:
> > > I can nuke E_STRICT altogether if u guys want.
> > > It's kind of a shame because I thought it might be nice for purists. I
> > > don't un
On Wed, 3 Dec 2003, Stig S. Bakken wrote:
>What we're trying to avoid is to force every package maintainer to roll
>PHP 5 specific releases for packages that still support PHP 4. Smooth
>transition requires that one package at a time can be transitioned, or
>we would create a dependency mess out
Hello Andi,
Wednesday, December 3, 2003, 12:57:19 PM, you wrote:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
Args, please let it in. It hel
Andi Gutmans wrote:
I can nuke E_STRICT altogether if u guys want.
It's kind of a shame because I thought it might be nice for purists. I
don't understand why it bothers ppl so much when they don't have to use it.
Please keep it... It will be usefull for people willing to write "good
PHP5 code".
Quoting Andi Gutmans <[EMAIL PROTECTED]>:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
>
I am with Derick, it should be in. The non-purist wo
On Wednesday 03 December 2003 12.59, Derick Rethans wrote:
> On Wed, 3 Dec 2003, Andi Gutmans wrote:
> > I can nuke E_STRICT altogether if u guys want.
> > It's kind of a shame because I thought it might be nice for purists. I
> > don't understand why it bothers ppl so much when they don't have to
On Wed, 3 Dec 2003, Andi Gutmans wrote:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
Please keep it in.
Derick
--
PHP Internals - PHP Runti
I can nuke E_STRICT altogether if u guys want.
It's kind of a shame because I thought it might be nice for purists. I
don't understand why it bothers ppl so much when they don't have to use it.
At 12:18 PM 12/3/2003 +0100, Christian Schneider wrote:
Stig S. Bakken wrote:
The goal here is to assur
Stig S. Bakken wrote:
The goal here is to assure smooth transition from PHP 4 to PHP 5 for
PEAR users. To me that means not having to use version_compare() or
have different versions of files for PHP 4 and 5.
I think you slightly mix up PEAR developers and PEAR users but I
completely agree with y
On Mon, 2003-12-01 at 21:47, Andi Gutmans wrote:
> At 03:32 PM 12/1/2003 -0500, Daniel Convissor wrote:
> >On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote:
> > >
> > > I don't quite understand the problem. E_STRICT was only meant for people
> > > who really want to be pedantic. I think
On Wed, 3 Dec 2003, Stig S. Bakken wrote:
> On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote:
> > At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote:
> > >For the next 18-24 months, we are going to have to deal with code
> > >running in both PHP 4 and 5. Why not declare "var" an alias for
> > >"pub
On Tue, 2003-12-02 at 18:43, Marcus Boerger wrote:
> Hello Christian,
>
> Tuesday, December 2, 2003, 1:14:12 PM, you wrote:
>
> > Andi Gutmans wrote:
> >> E_STRICT will be disabled by default. It is only meant for people who
> >> want to be sure that they are using the recommended methods, and t
On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote:
> At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote:
> >For the next 18-24 months, we are going to have to deal with code
> >running in both PHP 4 and 5. Why not declare "var" an alias for
> >"public", not throw E_STRICT for it and be done with it?
Hello Christian,
Tuesday, December 2, 2003, 7:18:11 PM, you wrote:
> Marcus Boerger wrote:
>> I see all your concerns. But from my point of view pear has (of course) the
>> problem that it is written in php4 and for php4. So PEAR needs to address
>> the move towards php5 code anyway. An optional
Andi Gutmans wrote:
Again, people don't have to use E_STRICT. I think having two new E_'s is
Why then introduce it at all? Or why not slightly change it to be useful
for a lot more people?
> a bit of an overkill especially as there aren't that many things we
> can add to them.
I think all of the
Again, people don't have to use E_STRICT. I think having two new E_'s is a
bit of an overkill especially as there aren't that many things we can add
to them.
At 07:18 PM 12/2/2003 +0100, Christian Schneider wrote:
Marcus Boerger wrote:
I see all your concerns. But from my point of view pear has
Marcus Boerger wrote:
I see all your concerns. But from my point of view pear has (of course) the
problem that it is written in php4 and for php4. So PEAR needs to address
the move towards php5 code anyway. An optional E_STRICT would help here
wouldn't it?
[My concern is that if E_STRICT warns abou
Hello Melvyn,
Tuesday, December 2, 2003, 10:53:17 AM, you wrote:
> On Tuesday 02 December 2003 09:18, Derick Rethans wrote:
>> On Tue, 2 Dec 2003, Melvyn Sopacua wrote:
>> > On Monday 01 December 2003 23:27, Derick Rethans wrote:
>> > > > I don't quite understand the problem. E_STRICT was only me
Hello Christian,
Tuesday, December 2, 2003, 1:14:12 PM, you wrote:
> Andi Gutmans wrote:
>> E_STRICT will be disabled by default. It is only meant for people who
>> want to be sure that they are using the recommended methods, and that
>> definitely includes not using var.
> The problem is that
Andi Gutmans wrote:
E_STRICT will be disabled by default. It is only meant for people who
want to be sure that they are using the recommended methods, and that
definitely includes not using var.
The problem is that it doesn't match the real world. People _are_ using
PEAR and people _are_ using P
At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote:
For the next 18-24 months, we are going to have to deal with code
running in both PHP 4 and 5. Why not declare "var" an alias for
"public", not throw E_STRICT for it and be done with it? If not this
issue will be a real PITA for PEAR users.
Stig,
Stig S. Bakken wrote:
For the next 18-24 months, we are going to have to deal with code
running in both PHP 4 and 5. Why not declare "var" an alias for
"public", not throw E_STRICT for it and be done with it? If not this
issue will be a real PITA for PEAR users.
+1 from me (not that my vote count
On Tuesday 02 December 2003 09:18, Derick Rethans wrote:
> On Tue, 2 Dec 2003, Melvyn Sopacua wrote:
> > On Monday 01 December 2003 23:27, Derick Rethans wrote:
> > > > I don't quite understand the problem. E_STRICT was only meant for
> > > > people who really want to be pedantic. I think we can ma
At 09:18 AM 12/2/2003 +0100, Derick Rethans wrote:
On Tue, 2 Dec 2003, Melvyn Sopacua wrote:
> On Monday 01 December 2003 23:27, Derick Rethans wrote:
>
> > > I don't quite understand the problem. E_STRICT was only meant for
people
> > > who really want to be pedantic. I think we can make it not
On Tue, 2 Dec 2003, Melvyn Sopacua wrote:
> On Monday 01 December 2003 23:27, Derick Rethans wrote:
>
> > > I don't quite understand the problem. E_STRICT was only meant for people
> > > who really want to be pedantic. I think we can make it not part of E_ALL.
> > > Is that OK?
> >
> > SOunds good
For the next 18-24 months, we are going to have to deal with code
running in both PHP 4 and 5. Why not declare "var" an alias for
"public", not throw E_STRICT for it and be done with it? If not this
issue will be a real PITA for PEAR users.
- Stig
On Sun, 2003-11-30 at 00:10, Andi Gutmans wrot
--- Melvyn Sopacua <[EMAIL PROTECTED]> wrote:
> If you're going to do this, then do it backwards compatible and
> 'leave' E_ALL at 2047 and move E_STRICT to 2048.
I like the idea of leaving E_ALL at 2047, but it's also quite intuitive
that E_ALL is the sum of all other error levels, and each of th
The var issue is probably going to affect pear, I would presume the plan
is to make all code 'parseable' by E_STRICT, and yet most pear packages
will retail PHP4 support for quite a while.
I guess well have to start doing @class { } :)
Regards
Alan
Andi Gutmans wrote:
At 03:32 PM 12/1/200
On Monday 01 December 2003 23:27, Derick Rethans wrote:
> > I don't quite understand the problem. E_STRICT was only meant for people
> > who really want to be pedantic. I think we can make it not part of E_ALL.
> > Is that OK?
>
> SOunds good to me, -Wall with gcc doesn't show all errors either...
On Mon, 1 Dec 2003, Andi Gutmans wrote:
> At 02:37 PM 12/1/2003 -0500, Daniel Convissor wrote:
> >On Sun, Nov 30, 2003 at 01:10:25AM +0200, Andi Gutmans wrote:
> > > The strict was introduced so that we can add warnings about practices we
> > > recommend and deprecated behavior.
> > > I think "var
At 03:32 PM 12/1/2003 -0500, Daniel Convissor wrote:
On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote:
>
> I don't quite understand the problem. E_STRICT was only meant for people
> who really want to be pedantic. I think we can make it not part of E_ALL.
> Is that OK?
Better. The only
On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote:
>
> I don't quite understand the problem. E_STRICT was only meant for people
> who really want to be pedantic. I think we can make it not part of E_ALL.
> Is that OK?
Better. The only drawback is people who do want to be pedantic wi
At 02:37 PM 12/1/2003 -0500, Daniel Convissor wrote:
On Sun, Nov 30, 2003 at 01:10:25AM +0200, Andi Gutmans wrote:
> The strict was introduced so that we can add warnings about practices we
> recommend and deprecated behavior.
> I think "var" belongs there.
> We could remove E_STRICT from E_ALL (al
On Sun, Nov 30, 2003 at 01:10:25AM +0200, Andi Gutmans wrote:
> The strict was introduced so that we can add warnings about practices we
> recommend and deprecated behavior.
> I think "var" belongs there.
> We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and
> save ppl the tr
Its a binary maths problem:
#define E_ALL (E_ERROR | E_WARNING | E_PARSE | E_NOTICE | E_CORE_ERROR |
E_CORE_WARNING | E_COMPILE_ERROR | E_COMPILE_WARNING | E_USER_ERROR |
E_USER_WARNING | E_USER_NOTICE)
I guess either slotting E_STRICT in the and defining E_ALL_PHP5 or
(E_ALL_PHP4 and redefini
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Sunday, November 30, 2003 12:10 AM
> The strict was introduced so that we can add warnings about practices we
> recommend and deprecated behavior.
> I think "var" belongs there.
> We could remove E_STRICT from E_ALL (although that'd be a bit
The strict was introduced so that we can add warnings about practices we
recommend and deprecated behavior.
I think "var" belongs there.
We could remove E_STRICT from E_ALL (although that'd be a bit hacky) and
save ppl the trouble of seeing these warnings.
Then again, we could remove the warning
Andi Gutmans wrote:
> If anyone here has time or has already tried running some popular PHP
> packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to
> hear about your experience and especially the problems.
Dunno if these are popular, but phpOpenTracker and XML_Transformer work
fi
On Fri, Nov 28, 2003 at 10:04:39AM +0100, Derick Rethans wrote:
>
> Strict is strict, that's the whole point. You can either fix your code
> or disable strict.
The "fixed" code can't run on PHP 4. This strict idea needs a minor
reevaluation. Using var in PHP 5 isn't really "broken" and in order
function table creation works fine, but as it doesn't use any
OO stuff at all it is not *that* astonishing ... ;)
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hello,
On Wed, Nov 26, 2003 at 05:32:29PM +0200, Andi Gutmans wrote:
> Hi guys,
>
> Now that we're at a very advanced stage and the code freeze is coming up, I
> think it'd be a good idea to start running some PHP 4 applications on PHP 5
> and see how easy things go. I'm sure we'll bump into so
On Thu, 27 Nov 2003, Daniel Convissor wrote:
> Greetings:
>
> I have been testing/tweaking PHP 5 via a major OOP based project of mine
> that relies on PEAR::DB. There are some major hangups, most of which I've
> mentioned in other places. To be complete, I'll touch on them here.
>
> 1) The "va
Greetings:
I have been testing/tweaking PHP 5 via a major OOP based project of mine
that relies on PEAR::DB. There are some major hangups, most of which I've
mentioned in other places. To be complete, I'll touch on them here.
1) The "var: Deprecated." warning from the new E_STRICT level is a
Andi, any chance of fixing this? I think there was a long thread on engine2
about this and there was an agreement that this should work as in php4.
Edin
On Thursday 27 November 2003 13:47, Derick Rethans wrote:
> On Thu, 27 Nov 2003, Edin Kadribasic wrote:
> > On Thursday 27 November 2003 11:47
Hello Stanislav,
Thursday, November 27, 2003, 3:32:25 PM, you wrote:
MB>>> It respects the refcoutning while destructing the zvals.
> I don't exacetly understand _how_ it respects them so that this solves the
> circular dependency problem. In fact, in the patch in the URL you have
> sent I don'
MB>> It respects the refcoutning while destructing the zvals.
I don't exacetly understand _how_ it respects them so that this solves the
circular dependency problem. In fact, in the patch in the URL you have
sent I don't even see one call to destructor. Also, does you patch take
into account th
Zitat von Edin Kadribasic <[EMAIL PROTECTED]>:
> On Thursday 27 November 2003 11:47, Jan Schneider wrote:
> [snip]
> > behaviour/notification and not working on-the-fly-generation of
> stdClass
> > objects. It's not that much of a problem for us as we will release new
>
> What exactly is the probl
On Thu, 27 Nov 2003, Edin Kadribasic wrote:
> On Thursday 27 November 2003 11:47, Jan Schneider wrote:
> [snip]
> > behaviour/notification and not working on-the-fly-generation of stdClass
> > objects. It's not that much of a problem for us as we will release new
>
> What exactly is the problem wi
Hello Stanislav,
Thursday, November 27, 2003, 1:28:36 PM, you wrote:
MB>>> Ok, sure we care in request shutdown but at least page delivery isn't
MB>>> affected by the patch.
> Definitely it is. The fact that it's _next_ page delivery that would be
> affected is not helping much - any page but
MB>> Ok, sure we care in request shutdown but at least page delivery isn't
MB>> affected by the patch.
Definitely it is. The fact that it's _next_ page delivery that would be
affected is not helping much - any page but the very first since server
run is the next for some page and it is reasonab
On Thursday 27 November 2003 11:47, Jan Schneider wrote:
[snip]
> behaviour/notification and not working on-the-fly-generation of stdClass
> objects. It's not that much of a problem for us as we will release new
What exactly is the problem with stdClass? We have a lot of code overhere that
rely o
Hello Stanislav,
Thursday, November 27, 2003, 1:00:20 PM, you wrote:
MB>>> with 1 < c < 1.1. Since we never cared about shutdown time this
MB>>> should be ok
> If we are talking about request shutdown, we definitely do care about it.
> Slower is the request shutdown, more time the httpd process
MB>> with 1 < c < 1.1. Since we never cared about shutdown time this
MB>> should be ok
If we are talking about request shutdown, we definitely do care about it.
Slower is the request shutdown, more time the httpd process/thread takes
per request, more load on the server.
--
Stanislav Malyshev,
Hello Derick,
Thursday, November 27, 2003, 11:54:07 AM, you wrote:
> Hey,
> On Wed, 26 Nov 2003, Andi Gutmans wrote:
>> Now that we're at a very advanced stage and the code freeze is coming up, I
>> think it'd be a good idea to start running some PHP 4 applications on PHP 5
>> and see how easy
Hi Andi,
On 26 Nov 2003, at 16:32, Andi Gutmans wrote:
If anyone here has time or has already tried running some popular PHP
packages such as php-nuke, phpbb, phpmyadmin and so on, I'd love to
hear about your experience and especially the problems.
I forwarded this to pear-dev. I know that some p
Hey,
On Wed, 26 Nov 2003, Andi Gutmans wrote:
> Now that we're at a very advanced stage and the code freeze is coming up, I
> think it'd be a good idea to start running some PHP 4 applications on PHP 5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of them might be
Zitat von Andi Gutmans <[EMAIL PROTECTED]>:
> Hi guys,
>
> Now that we're at a very advanced stage and the code freeze is coming up,
> I
> think it'd be a good idea to start running some PHP 4 applications on PHP
> 5
> and see how easy things go. I'm sure we'll bump into some issues and many
> of
What had to be patched? Is it something we can fix or add to a
compatibility mode?
Andi
At 11:24 AM 11/27/2003 +0100, Marcus Boerger wrote:
Hello Ivan,
same for me with a two weeks old 5b2-dev. It also runs other applications
and only one had to be patched (i didn't knew it was running n the se
Great to hear that!
At 10:51 AM 11/27/2003 +0100, Ivan Rodriguez wrote:
Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
perfect.
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 26,
Hello Ivan,
same for me with a two weeks old 5b2-dev. It also runs other applications
and only one had to be patched (i didn't knew it was running n the server).
Thursday, November 27, 2003, 10:51:34 AM, you wrote:
> Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
> perfe
Hi Andi, I try phpmyadmin with php 5.0.0beta1 under Red Hat 9 and works
perfect.
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Wednesday, November 26, 2003 4:32 PM
Subject: [PHP-DEV] Compatibility problems with PHP 5
> Hi
61 matches
Mail list logo
