PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (751 total including feature requests)
===[*General Issues]==
26223 Feedback Error message makes PHP crash (in some special cases)
27372 Verified parse error loadin
All,
Yesterday, someone complained that classes that implement interfaces
succeed in doing so even when they don't satisfy the prototypes. While
this does cause an E_STRICT message to be emitted, it would go unnoticed in
most cases, as E_STRICT is off by default, in some cases - even when peop
On Mon, 19 Apr 2004, Zeev Suraski wrote:
> Suggested behavior:
> Any method that implements (directly or indirectly) an interface method or
> an abstract method, will have implementation checks fully enforced, with an
> E_COMPILE_ERROR emitted in case of an error.
> Behavior for methods that overr
Zeev Suraski wrote:
Any method that implements (directly or indirectly) an interface method
or an abstract method, will have implementation checks fully enforced,
with an E_COMPILE_ERROR emitted in case of an error.
Excuse my ignorance: What is defined as fully implementing the
interface? I gues
Hey,
I just wanted to note the fact that I disagree with this.
In a perfect world, I would go with an E_COMPILE_ERROR in all situations;
when inheriting regular classes (w/o abstract methods), abstract methods
and interfaces. That is what the academic part of me feels but knows can't
be done.
A
At 13:01 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
Any method that implements (directly or indirectly) an interface method
or an abstract method, will have implementation checks fully enforced,
with an E_COMPILE_ERROR emitted in case of an error.
Excuse my ignorance: What is defi
At 13:04 19/04/2004, Andi Gutmans wrote:
Hey,
I just wanted to note the fact that I disagree with this.
In a perfect world, I would go with an E_COMPILE_ERROR in all situations;
when inheriting regular classes (w/o abstract methods), abstract methods
and interfaces. That is what the academic par
Andi Gutmans wrote:
> aggressive approach of E_COMPILE_ERROR
+1 :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing Lis
For interfaces and abstract methods?
At 12:17 PM 4/19/2004 +0200, Sebastian Bergmann wrote:
Andi Gutmans wrote:
> aggressive approach of E_COMPILE_ERROR
+1 :)
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle
Zeev Suraski wrote:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are out
I'm not sure I understand what you mean by everything.
whole interface/abstract/class type hints mechanism was added for the
sole reason
php.ini-dist in HEAD has the following value:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
It's odd that E_STRICT is explicitly excluded as E_ALL does not include
it. Is there a purpose to it? Perhaps it's something I don't know
about ;)
Kenneth
--
PHP Internals - PHP Runtime Developmen
On Mon, 19 Apr 2004, Kenneth Schwartz wrote:
> php.ini-dist in HEAD has the following value:
>
> error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
>
> It's odd that E_STRICT is explicitly excluded as E_ALL does not include
> it. Is there a purpose to it? Perhaps it's something I don't know
> abo
I guess it's just verbosity.
At 06:30 AM 4/19/2004 -0400, Kenneth Schwartz wrote:
php.ini-dist in HEAD has the following value:
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
It's odd that E_STRICT is explicitly excluded as E_ALL does not include
it. Is there a purpose to it? Perhaps it's s
Andi Gutmans wrote:
> For interfaces and abstract methods?
Both.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailing List
And regular old-style inheritance?
At 12:45 PM 4/19/2004 +0200, Sebastian Bergmann wrote:
Andi Gutmans wrote:
> For interfaces and abstract methods?
Both.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-sof
On Monday 19 April 2004 10.49, Zeev Suraski wrote:
> Suggested behavior:
> Any method that implements (directly or indirectly) an interface method or
> an abstract method, will have implementation checks fully enforced, with an
> E_COMPILE_ERROR emitted in case of an error.
> Behavior for methods t
At 13:28 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are out
I'm not sure I understand what you mean by everything.
Everything means for both overriding
Zeev Suraski wrote:
In my opinion it doesn't, because it breaks the interface of the parent
class. I.e., you can no longer use code you've written to work with an
object of the parent class, with an object of the child class, which
breaks one of the most fundamental principals of OO. In turn,
At 14:40 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
In my opinion it doesn't, because it breaks the interface of the parent
class. I.e., you can no longer use code you've written to work with an
object of the parent class, with an object of the child class, which
breaks one of t
On Mon, 19 Apr 2004, Zeev Suraski wrote:
> At 14:40 19/04/2004, Christian Schneider wrote:
> >Zeev Suraski wrote:
> >>In my opinion it doesn't, because it breaks the interface of the parent
> >>class. I.e., you can no longer use code you've written to work with an
> >>object of the parent class,
Zitat von Zeev Suraski <[EMAIL PROTECTED]>:
At 13:01 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
Any method that implements (directly or indirectly) an interface
method or an abstract method, will have implementation checks fully
enforced, with an E_COMPILE_ERROR emitted in case o
On 19 Apr 2004 at 11:49, Zeev Suraski wrote:
> Suggested behavior:
> Any method that implements (directly or indirectly) an interface
method or
> an abstract method, will have implementation checks fully
enforced, with an
> E_COMPILE_ERROR emitted in case of an error.
> Behavior for methods th
On Sunday 11 April 2004 23:16, Marcus Boerger wrote:
> Hello Marc,
[...]
> >
> > I read that for simple cases, instantiation before declaration will
> > work...does/will this cause an E_STRICT error?
>
> no but probabla something to discuss since maybe later it won't work
> anymore and it is 'not s
Zeev Suraski wrote:
At 13:28 19/04/2004, Christian Schneider wrote:
Zeev Suraski wrote:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are out
I'm not sure I understand what you mean by everything.
Everyth
On Monday 19 April 2004 16.10, Ferdinand Beyer wrote:
>
> > Comments welcome - we'd like to sort this out before RC2...
>
> I don't like the idea as it does not allow var args to emulate
> overloaded methods. I repeat myself when I say that IMO such
> strictness does not fit to PHP's loose characte
Magnus Määttä wrote:
If you don't want strictness, don't use interfaces. If this doesn't get
I agree. Which also means that the PHP core and extensions should be
written without interfaces to avoid forcing people to use them.
Otherwise you end up with an extension you can't use with another
fra
I agree. Interfaces are useless if you can't guarantee that a class
actually implements them. Violating an interface is violating a contract
and it should be an compile error - indeed, when coding I mostly rely on not
properly implementing interfaces to be a compile error.
-Sterling
-Origin
Yes, but I claim that inheritance is exactly the same thing. I comes with
an interface which needs to be adhered to. It does tend to be inconsistent
if we E_ERROR out on interfaces and not on inheritance.
At 09:31 AM 4/19/2004 -0700, Sterling Hughes wrote:
I agree. Interfaces are useless if you
Is there a easy way to change the internal soname?
I need to build the embeded sapi with a different internal soname.
Yes, I can rename libphp4.so (the embeded version) to libphp4-embed.so,
but things that link with libphp4-embed.so will have a dependency of
libphp.so because that is what the
Hello Ferdinand,
Monday, April 19, 2004, 4:10:29 PM, you wrote:
> On 19 Apr 2004 at 11:49, Zeev Suraski wrote:
>> Suggested behavior:
>> Any method that implements (directly or indirectly) an interface
> method or
>> an abstract method, will have implementation checks fully
> enforced, with a
Hello Zeev,
Monday, April 19, 2004, 12:14:40 PM, you wrote:
> At 13:04 19/04/2004, Andi Gutmans wrote:
>>Hey,
>>
>>I just wanted to note the fact that I disagree with this.
>>In a perfect world, I would go with an E_COMPILE_ERROR in all situations;
>>when inheriting regular classes (w/o abstract
Hello Derick,
i think we should leave it in because we might remove it from E_ALL in later
php versions.
marcus
Monday, April 19, 2004, 12:46:44 PM, you wrote:
> On Mon, 19 Apr 2004, Kenneth Schwartz wrote:
>> php.ini-dist in HEAD has the following value:
>>
>> error_reporting = E_ALL & ~E_N
On Mon, 19 Apr 2004, Marcus Boerger wrote:
> i think we should leave it in because we might remove it from E_ALL in later
> php versions.
Uh? E_STRICT is not part of E_ALL, but in case you meant it the other
way around I agree, let's leave it there :)
Derick
--
PHP Internals - PHP Runtime Deve
> Hello Derick,
> i think we should leave it in because we might remove it from E_ALL in later
> php versions.
Erm i meant we may add E_STRICT to E_ALL in a later version.
> marcus
> Monday, April 19, 2004, 12:46:44 PM, you wrote:
>> On Mon, 19 Apr 2004, Kenneth Schwartz wrote:
>>> php.ini-di
Hey Brian,
Would something as simple as this:
LDFLAGS="-soname=libphp4-embed.so" ./configure ...
work ?
--Wez.
- Original Message -
From: "Brian J. France" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, April 19, 2004 7:29 PM
Subject: [PHP-DEV] Changing the soname of libphp
On Apr 19, 2004, at 2:49 PM, Marcus Boerger wrote:
Hello Zeev,
Monday, April 19, 2004, 12:14:40 PM, you wrote:
At 13:04 19/04/2004, Andi Gutmans wrote:
Hey,
I just wanted to note the fact that I disagree with this.
In a perfect world, I would go with an E_COMPILE_ERROR in all
situations;
when
Nothing seemed to work, I tried adding that (and a few variations)
before ./configure line and also tried editing the config.m4 for the
sapi and adding it there.
I did get it to work by hand editing the Makefile and changing the
libphp4.la action. I changed:
-o $@
to
-o libphp4-embed.la
a
Marcus Boerger wrote:
Erm i meant we may add E_STRICT to E_ALL in a later version.
... which would be a big BC break. Remember that 'var' produces a
warning under E_STRICT. And 'var' is here to stay for a *long* time.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe
Hello Christian,
then obviously E_STRICT must stay out of E_ALL for long time.
Still explicitly showing there's more is a good thing. Maybe
some text near the setting would be good.
marcus
Monday, April 19, 2004, 11:29:07 PM, you wrote:
> Marcus Boerger wrote:
>> Erm i meant we may add E_STRIC
George Schlossnagle wrote:
Just to clarify a bit on why I think that we should differentiate:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are
+1
Are you guys serious about a compile error if I override a method
On Apr 19, 2004, at 5:37 PM, Christian Schneider wrote:
George Schlossnagle wrote:
Just to clarify a bit on why I think that we should differentiate:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are
+1
Are you gu
On Apr 19, 2004, at 5:45 PM, George Schlossnagle wrote:
On Apr 19, 2004, at 5:37 PM, Christian Schneider wrote:
George Schlossnagle wrote:
Just to clarify a bit on why I think that we should differentiate:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for eve
George Schlossnagle wrote:
1. First of all, I agree that in a perfect world we should go with
E_COMPILE_ERROR for everything. Maybe now that's constructors are
+1
Are you guys serious about a compile error if I override a method with
different parameters? This must be the mailing list of a diffe
mo compile errors mo better.
+1.
-Sterling
On Apr 19, 2004, at 12:52 PM, George Schlossnagle wrote:
On Apr 19, 2004, at 2:49 PM, Marcus Boerger wrote:
Hello Zeev,
Monday, April 19, 2004, 12:14:40 PM, you wrote:
At 13:04 19/04/2004, Andi Gutmans wrote:
Hey,
I just wanted to note the fact tha
It is. This is a mailing list discussing for discussing the use of
exceptions and compile errors in java. If you are not interested in
that, please unsubscribe.
-Sterling
On Apr 19, 2004, at 2:37 PM, Christian Schneider wrote:
George Schlossnagle wrote:
Just to clarify a bit on why I think t
Hi,
Zeev Suraski wrote:
>
> What I'm asking is that, short of enabling these checks for everything
> (as defined above) due to significant opposition, we should at least
> re-enable them for interface/abstract methods (this was the way things
> were for about half a year, until the previous discu
I would prefer an ini option, while on a
development or testing server interfaces are great, I would love to be
able to reduce this to a E_NOTICE on a live server, and stuff it in an
error log...
Regards
Alan
Zeev Suraski wrote:
All,
Yesterday, someone complained that classes that implement in
I added two new functions for handling output filters in the Apache2
Handler SAPI:
bool apache_add_output_filter(string filter_name) - Attempts to add the
named filter to the Filter Chain.
array apache_get_output_filters() - Returns an array of all Active
Output filters for this request.
The abi
48 matches
Mail list logo
