Zeev Suraski wrote:
If you take into account that [a] in PHP, you cannot have more than one
signature for a method in a given class, and you take into account the
fact that [b] your overriding method must be able to satisfy the same
interface as the method its overriding
The real solution is
Hello Timm,
Friday, February 27, 2004, 7:39:26 PM, you wrote:
> On Fri, 2004-02-27 at 14:39, Stig S. Bakken wrote:
>> On Fri, 2004-02-27 at 14:13, Derick Rethans wrote:
> [...]
>> What is worse is that many PHP 4 APIs need to be completely redesigned
>> for PHP 5, not only the guts of the class.
On Fri, 2004-02-27 at 14:39, Stig S. Bakken wrote:
> On Fri, 2004-02-27 at 14:13, Derick Rethans wrote:
[...]
> What is worse is that many PHP 4 APIs need to be completely redesigned
> for PHP 5, not only the guts of the class.
>
> IMHO method overloading the the only clean way out of this.
Agre
On Fri, 27 Feb 2004, Andi Gutmans wrote:
> What I suggest is the following:
> a) Don't check signature for constructors.
> b) By default, don't check signature for inheritance *if* we're not
> inheriting from an abstract class. If it is an abstract class we should
> check the signature because it
At 10:25 27/02/2004 -0500, Hans Lellelid wrote:
Hi -
Andi Gutmans wrote:
The question is if we should ignore constructors from this check. I think
we should but one person here thought we shouldn't.
I think constructors should be ignored.
OK
Is everyone OK with peforming this check for abstract
Hi -
Andi Gutmans wrote:
The question is if we should ignore constructors from this check. I
think we should but one person here thought we shouldn't.
I think constructors should be ignored.
Is everyone OK with peforming this check for abstract classes and
interfaces? Or do you think it should
On Fri, 27 Feb 2004, Andi Gutmans wrote:
> At 14:13 27/02/2004 +0100, Derick Rethans wrote:
> >On Fri, 27 Feb 2004, Andi Gutmans wrote:
> >
> > > d) Last problem is that using E_STRICT is not a good idea because we find
> > > this problem at compile-time and the error_reporting might not be set ye
On Feb 27, 2004, at 10:05 AM, Andi Gutmans wrote:
Yeah but people are used to setting the error_reporting from prepend's
or at the beginning of the script. But you know what, I guess we can
live with this because I see a few E_WARNINGS at the compile stage. So
I guess we could go with E_STRICT f
At 14:13 27/02/2004 +0100, Derick Rethans wrote:
On Fri, 27 Feb 2004, Andi Gutmans wrote:
> d) Last problem is that using E_STRICT is not a good idea because we find
> this problem at compile-time and the error_reporting might not be set yet.
The INI system is 'booted' before the script is compile
On Fri, 2004-02-27 at 14:13, Derick Rethans wrote:
> On Fri, 27 Feb 2004, Andi Gutmans wrote:
>
> > d) Last problem is that using E_STRICT is not a good idea because we find
> > this problem at compile-time and the error_reporting might not be set yet.
>
> The INI system is 'booted' before the sc
George Schlossnagle wrote:
On Feb 27, 2004, at 4:12 AM, Andi Gutmans wrote:
Hey,
I'd like to come to some conclusion about the latest changes which
break BC (trying to keep it short because some people here wrote long
essays and it took me too much time to catch up :) :
a) I agree that it does
On Feb 27, 2004, at 4:12 AM, Andi Gutmans wrote:
Hey,
I'd like to come to some conclusion about the latest changes which
break BC (trying to keep it short because some people here wrote long
essays and it took me too much time to catch up :) :
a) I agree that it doesn't make much sense for con
On Fri, 27 Feb 2004, Andi Gutmans wrote:
> d) Last problem is that using E_STRICT is not a good idea because we find
> this problem at compile-time and the error_reporting might not be set yet.
The INI system is 'booted' before the script is compiled, so I doubt
that this is a problem.
> What I
On Friday 27 February 2004 11:12, Ferdinand Beyer wrote:
> On 27 Feb 2004 at 10:58, Patrick Schnorbus wrote:
> > Mhm. Does a signature make sense if the engine ignores it
>
> anyway?
>
> > For better readability one can use phpdoc/doxygen like comment
>
> blocks.
>
> That's right. But I don't see a
On Friday 27 February 2004 10:12, Andi Gutmans wrote:
> What I suggest is the following:
> a) Don't check signature for constructors.
Okie ;)
> b) By default, don't check signature for inheritance *if* we're not
> inheriting from an abstract class.
> If it is an abstract class we should
> check
Andi Gutmans wrote:
b) By default, don't check signature for inheritance *if* we're not
inheriting from an abstract class. If it is an abstract class we should
check the signature because it's a PHP 5 feature.
Do you mean :
- check the signature only for methods which were in the abstract class
== Quote from Andi Gutmans ([EMAIL PROTECTED])'s article
> a) Don't check signature for constructors.
Constructors are definitely not virtual methods. So no reason to check signature.
Moreover, this is a non sense to declare constructors in interfaces or abstract
constructors in abstract classes.
On 27 Feb 2004 at 10:58, Patrick Schnorbus wrote:
> Mhm. Does a signature make sense if the engine ignores it
anyway?
> For better readability one can use phpdoc/doxygen like comment
blocks.
That's right. But I don't see a reason why we should disallow to use a
signature in an interface declar
On Friday 27 February 2004 10:41, Ferdinand Beyer wrote:
> On 27 Feb 2004 at 11:12, Andi Gutmans wrote:
> > Comments? (Please try to keep them short :)
>
> I think we should just drop the signature check. Interfaces may
> include a signature for better readability but the engine should ignore
> the
AG>> c) Add a new INI option (zend.strict_inheritance_checks) which
AG>> does check signature for methods (except for constructor). I
AG>> don't like new INI options but I don't think there's any way
AG>> out.
There's a dilemma about this option. On one hand, it should be on by
default. Otherwise,
On 27 Feb 2004 at 11:12, Andi Gutmans wrote:
> Comments? (Please try to keep them short :)
I think we should just drop the signature check. Interfaces may
include a signature for better readability but the engine should ignore
them. PHP4 class trees work fine even without strict inheritance
ch
Hey,
I'd like to come to some conclusion about the latest changes which break BC
(trying to keep it short because some people here wrote long essays and it
took me too much time to catch up :) :
a) I agree that it doesn't make much sense for constructors, because one
always creates concrete cl
Ferdinand Beyer wrote:
IMO we are trying to force a strict programming here that is
incompatible with PHP's loose character.
Yeah, I absolutely agree with that. The more I think about it the more
it also seems like this change is going to break a *lot* of PHP code out
there. Especially the e
Marcus Boerger wrote:
Hello Timm,
i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules. And as a
consequence maybe interfaces shouldn't allow constructors.
Does inheritance include visibility rules? ;)
Andrey
--
PHP Inter
On Feb 26, 2004, at 1:49 AM, Andi Gutmans wrote:
You are breaking the isA relationship. We fixed this so that from now
on, people will not make such mistakes anymore (I think it's the right
way to go, so that we don't leave broken functionality around).
You can enable compatibility mode to make
Hello Andrey,
Thursday, February 26, 2004, 1:08:19 PM, you wrote:
> Marcus Boerger wrote:
>> Hello Timm,
>>
>> i had the same expirience today too. And also for me it makes not much
>> sense. The constructor shouldn't check inheritance rules. And as a
>> consequence maybe interfaces shouldn't al
At 03:28 26/02/2004, Derick Rethans wrote:
On Thu, 26 Feb 2004, Marcus Boerger wrote:
> Hello Timm,
>
> well for normal methods we must do that. The derived class must support the
> same signature that the base class supports. In you example that would only
> work if the derived method would have
At 07:19 26/02/2004, Hans Lellelid wrote:
Ferdinand Beyer wrote:
IMO we are trying to force a strict programming here that is incompatible
with PHP's loose character.
Yeah, I absolutely agree with that. The more I think about it the more it
also seems like this change is going to break a *lot*
On Feb 26, 2004, at 11:49 PM, Zeev Suraski wrote:
At 07:19 26/02/2004, Hans Lellelid wrote:
Ferdinand Beyer wrote:
IMO we are trying to force a strict programming here that is
incompatible with PHP's loose character.
Yeah, I absolutely agree with that. The more I think about it the
more it als
Hi Zeev -
Thanks for the response.
Zeev Suraski wrote:
If you take into account that [a] in PHP, you cannot have more than one
signature for a method in a given class, and you take into account the
fact that [b] your overriding method must be able to satisfy the same
interface as the method it
On Fri, 27 Feb 2004, George Schlossnagle wrote:
> This is an enormously huge bc break. Error-prone or not, I would wager
> that 95%+ of all php4 OO code exploits the ability to redefine the
> signature on inherited methods.
So far, I've identified that this breaks more than one important PEAR
pa
Ferdinand Beyer wrote:
IMO we are trying to force a strict programming here that is
incompatible with PHP's loose character.
Well, I don't get the point in relation to *constructors* at all.. I
mean, forcing the same signature for each constructor seems unreasonable
to me (_when explicitely cal
IMO we are trying to force a strict programming here that is
incompatible with PHP's loose character.
The following example for instance is very common in Java AVT
programming:
Furthermore with the new implementation we disallow "the PHP way
for overloaded methods" using a variable parameter
On Thu, 26 Feb 2004, Marcus Boerger wrote:
> Hello Timm,
>
> well for normal methods we must do that. The derived class must support the
> same signature that the base class supports. In you example that would only
> work if the derived method would have a default parameter for the additional
> pa
On Thu, 26 Feb 2004, Timm Friebe wrote:
> On Thu, 2004-02-26 at 01:38, Marcus Boerger wrote:
> > Hello Timm,
> [...]
> > > Should work #1, Bar::connect() adds an argument
> > No the sugnature is incompatible. An instance of Foo cannot be called
> > with Bar or Connector's connect() Signature. Henc
On Thu, 26 Feb 2004, Andi Gutmans wrote:
> At 18:54 25/02/2004 -0500, Hans Lellelid wrote:
> >It seems now that PHP is no longer inconsistent, but it also seems that it
> >is impossible to override methods w/ incompatible signature. Is that a
> >correct assessment? This is a pretty big differenc
Timm Friebe wrote:
[EMAIL PROTECTED]:~/devel/php/tests > cat inheritance.php
class Foo {
function __construct($foo) {
}
}
class Bar extends Foo {
function __construct($foo, $bar) {
// Add = NULL after $bar to make it work
}
}
?>
[EMAIL PROTECTED]:~/devel/php/te
At 08:03 26/02/2004 +0100, Timm Friebe wrote:
On Thu, 2004-02-26 at 07:49, Andi Gutmans wrote:
> At 23:36 25/02/2004 +0100, Timm Friebe wrote:
[...]
> Guys,
>
> You are breaking the isA relationship. We fixed this so that from now on,
> people will not make such mistakes anymore (I think it's the r
On Thu, 2004-02-26 at 07:49, Andi Gutmans wrote:
> At 23:36 25/02/2004 +0100, Timm Friebe wrote:
[...]
> Guys,
>
> You are breaking the isA relationship. We fixed this so that from now on,
> people will not make such mistakes anymore (I think it's the right way to
> go, so that we don't leave br
At 18:54 25/02/2004 -0500, Hans Lellelid wrote:
It seems now that PHP is no longer inconsistent, but it also seems that it
is impossible to override methods w/ incompatible signature. Is that a
correct assessment? This is a pretty big difference from PHP4,
then. Personally, I can live with i
At 23:52 25/02/2004 +0100, Timm Friebe wrote:
On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
> Hello Timm,
>
> i had the same expirience today too. And also for me it makes not much
> sense. The constructor shouldn't check inheritance rules.
Neither should other methods follow this. What if I w
At 23:36 25/02/2004 +0100, Timm Friebe wrote:
[EMAIL PROTECTED]:~/devel/php/tests > cat inheritance.php
class Bar extends Foo {
function __construct($foo, $bar) {
// Add = NULL after $bar to make it work
}
}
?>
[EMAIL PROTECTED]:~/devel/php/tests > php-dev inheritance.php
Fatal e
On Thu, 2004-02-26 at 02:38, Marcus Boerger wrote:
> Hello Timm,
[...]
> Yes! Maybe it would be good to apply the correct rules with E_COMPILE_ERROR
> in cases where interfaces come into play and E_STRICT for compatibility mode
> and non interfaces. Would that work for you?
Yupp, that's perfect.
On Thu, 2004-02-26 at 02:13, Timm Friebe wrote:
> On Thu, 2004-02-26 at 01:38, Marcus Boerger wrote:
> > Hello Timm,
> [...]
> > > Should work #1, Bar::connect() adds an argument
> > No the sugnature is incompatible. An instance of Foo cannot be called
> > with Bar or Connector's connect() Signatur
On Thu, 26 Feb 2004, Marcus Boerger wrote:
> well for normal methods we must do that. The derived class must support the
> same signature that the base class supports. In you example that would only
> work if the derived method would have a default parameter for the additional
> parameter:
>
>
Hello Timm,
Hello Zeev, please have a look at this thread. Obviously you started
a huge BC break here. See my second comment on a possible way out.
Thursday, February 26, 2004, 2:13:48 AM, you wrote:
> On Thu, 2004-02-26 at 01:38, Marcus Boerger wrote:
>> Hello Timm,
> [...]
>> > Should work #1,
On Thu, 2004-02-26 at 01:38, Marcus Boerger wrote:
> Hello Timm,
[...]
> > Should work #1, Bar::connect() adds an argument
> No the sugnature is incompatible. An instance of Foo cannot be called
> with Bar or Connector's connect() Signature. Hence Bar is not a Foo
> or Connector.
Hrm, that's quite
Hello Timm,
Thursday, February 26, 2004, 12:34:31 AM, you wrote:
> On Wed, 2004-02-25 at 23:52, Timm Friebe wrote:
>> On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
>> > Hello Timm,
>> >
>> > i had the same expirience today too. And also for me it makes not much
>> > sense. The constructor s
Timm Friebe wrote:
On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
Hello Timm,
i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules.
Neither should other methods follow this. What if I want to add a
non-default parame
On Wed, 2004-02-25 at 23:52, Timm Friebe wrote:
> On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
> > Hello Timm,
> >
> > i had the same expirience today too. And also for me it makes not much
> > sense. The constructor shouldn't check inheritance rules.
>
> Neither should other methods follow
Hello Timm,
well for normal methods we must do that. The derived class must support the
same signature that the base class supports. In you example that would only
work if the derived method would have a default parameter for the additional
parameter:
regards
marcus
Wednesday, February 25, 20
On Wed, 2004-02-25 at 23:44, Marcus Boerger wrote:
> Hello Timm,
>
> i had the same expirience today too. And also for me it makes not much
> sense. The constructor shouldn't check inheritance rules.
Neither should other methods follow this. What if I want to add a
non-default parameter to an ove
Hello Timm,
i had the same expirience today too. And also for me it makes not much
sense. The constructor shouldn't check inheritance rules. And as a
consequence maybe interfaces shouldn't allow constructors.
marcus
Wednesday, February 25, 2004, 11:36:57 PM, you wrote:
> [EMAIL PROTECTED]:~/dev
[EMAIL PROTECTED]:~/devel/php/tests > cat inheritance.php
[EMAIL PROTECTED]:~/devel/php/tests > php-dev inheritance.php
Fatal error: Declaration of Bar::__construct() must be compatible with
that of Foo::__construct() in
/usr/home/thekid/devel/php/tests/inheritance.php on line 10
Is this reall
54 matches
Mail list logo
