On Fri Aug 20 09:10 AM, Jonathan Bond-Caron wrote:
>
> Maybe Stas can comment but I can't reproduce the E_STRICT warning Is
> this php HEAD?
>
> class ObjParent {
> function set($param2 = '') {}
> }
>
> class ObjChild extends ObjParent {
> function set(){ echo "."; }
> }
>
M
You can not reproduce as long your php is misconfigured
error_reporting = E_ALL | E_STRICT
We are using this setting on ALL our production servers
to develop really clean applications
Strict Standards: Declaration of ObjChild::set() should be compatible with that
of ObjParent::set() in /home/harr
On Fri Aug 20 08:24 AM, Nathan Rixham wrote:
> Jonathan Bond-Caron wrote:
> > On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
> >> No it's wrong.
> >>
> >> A Child is a Parent so we must be able to pass a Parent to the
> method
> >> equals() defined on Child.
> >>
> >> The declaration of the par
Jonathan Bond-Caron wrote:
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
Maybe my OO theory is
On Fri Aug 20 06:54 AM, Jean-Sébastien H. wrote:
> No it's wrong.
>
> A Child is a Parent so we must be able to pass a Parent to the method
> equals() defined on Child.
>
> The declaration of the parent functions must always be valid in the
> children.
>
Maybe my OO theory is wrong but I was
You can..
--Original Message--
From: "Jean-Sébastien H."
To: nrix...@gmail.com
Cc: postmas...@colder.ch
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] inheritance check too strict?
Sent: 20 Aug 2010 11:54
No it's wrong.
A Child is a Parent so we must be able to pass
No it's wrong.
A Child is a Parent so we must be able to pass a Parent to the method
equals() defined on Child.
The declaration of the parent functions must always be valid in the
children.
On Thu, 19 Aug 2010 23:16:41 +0100, Nathan Rixham
wrote:
> lol, got it - confused myself for a bit ther
postmas...@colder.ch wrote:
- "Nathan Rixham" wrote:
class Point2DManager {
public function distanceBetween( Point2D $p1 , Point2D $p2 ) {};
}
class Point3DManager extends Point2DManager {
public function distanceBetween( Point3D $p1 , Point3D $p2 ) {};
}
This is i
- "Nathan Rixham" wrote:
> Chris Stockton wrote:
> > Hello,
> >
> > On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham
> wrote:
> >> Guys, this is going a bit nuts, let's swap all the Foo and Bar's
> for a real
> >> example - Zeev I've copied the way you specified above.
> >
> > I think your
Chris Stockton wrote:
Hello,
On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham wrote:
Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a real
example - Zeev I've copied the way you specified above.
I think your misunderstanding his position. To summarize my
understanding: h
Hello,
On Thu, Aug 19, 2010 at 12:33 PM, Nathan Rixham wrote:
> Guys, this is going a bit nuts, let's swap all the Foo and Bar's for a real
> example - Zeev I've copied the way you specified above.
I think your misunderstanding his position. To summarize my
understanding: he clearly states that
Zeev Suraski wrote:
At 17:04 19/08/2010, Ionut G. Stan wrote:
I can't call Child::foo() with an instance of Taz, but I can call
Parent::foo() with such an instance. So, I can't use instances of
Child wherever instances of Parent would be accepted.
Child should clearly not be allowed to inhe
Hi!
However, what are the benefits to be less strict in your example? I
can't think of any practical (or critical) example where you have to
remove this optional argument.
I have tons of code that does it, but the first example would be, of
course, using func_get_args().
Another example would
Hi!
I know that you know this, but I want this to be clear:
the extra args ignored only from the class definition point of view,
they can be harvested by the func_get_args() function.
Right. Same can happen when inheriting, of course. There's no additional
restriction when defining a method t
hi Stas,
On Thu, Aug 19, 2010 at 6:53 PM, Stas Malyshev wrote:
>> Arguments being silently ignored sounds like a potential bug to me. I
>> know it's something I've seen in code I've maintained.
>
> No, it's not a bug - extra arguments were silently ignored in PHP since the
> dawn of time.
Incon
>
>
> Arguments being silently ignored sounds like a potential bug to me. I
>> know it's something I've seen in code I've maintained.
>>
>
> No, it's not a bug - extra arguments were silently ignored in PHP since the
> dawn of time.
I know that you know this, but I want this to be clear:
the ext
Hi!
Maybe I didn't express myself clearly: I meant that the arguments in the
child's signature must be a superset of the arguments in the parent
signature, in the same order. Any required arguments in the parent may
It was clear to me you said that, however it is in no way clear why it
must be
Hi!
transparently, because they're specialized of ObjParent. If this
function signature was allowed - it can end up calling
ObjChild::set() with an argument - which ObjChild() doesn't support.
But it does! It just silently ignores the argument - which it does not
need. But you can add as muc
Hi!
class A {
public function foo(Foo $a = null) {}
}
class B extends A {
public function foo() {}
}
class C extends B {
public function foo(Bar $a = null) {}
}
Here B::foo() is compatible with A:foo() and as the parameter is
optional C::foo() is compatible with B::foo(). But C
Title: Document sans nom
I consider having type in the declaration of a method a bad idea and
this thread just prove it.
You can also read this:
http://gbracha.blogspot.com/2009/09/systemic-overload.html
On 08/19/2010 10:32 AM, Johannes Schlüter wrote:
On Thu, 2010-08-19 at 01:13 -0700, Sta
At 17:04 19/08/2010, Ionut G. Stan wrote:
class Parent
{
public function foo(Foo $foo)
{}
}
class Child
{
public function foo(Bar $bar)
{}
}
class Foo
{}
class Bar extends Foo
{}
All fine until here, but what if...
class Taz extends Foo.
{}
I can't call Child::foo() wit
At 10:51 19/08/2010, Stas Malyshev wrote:
Hi!
I recently noticed this code:
produces a E_STRICT warning. I don't really see a point in it -
there's no problem whatsoever with child function ignoring some
arguments from parent call. Anybody could explain why this check is there?
As others no
On 19/Aug/10 4:16 PM, Ryan Panning wrote:
Nathan Rixham wrote:
what if Bar implements Foo, or Bar extends Foo - surely that should be
compatible given the inheritance chain.
I ran into this exact issue and thought it was strange. Is there a
reason this shouldn't be allowed?
It still breaks t
Nathan Rixham wrote:
what if Bar implements Foo, or Bar extends Foo - surely that should be
compatible given the inheritance chain.
I ran into this exact issue and thought it was strange. Is there a
reason this shouldn't be allowed?
--
PHP Internals - PHP Runtime Development Mailing List
To
2010/8/19 Johannes Schlüter :
> On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
>> Hi!
>>
>> > I was under the impression that, in order for inheritance to provide
>> > proper polymorphism, overridden methods should share the parent's method
>> > signature, although they can have additional
Johannes Schlüter wrote:
On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
Hi!
I was under the impression that, in order for inheritance to provide
proper polymorphism, overridden methods should share the parent's method
signature, although they can have additional optional arguments.
Yo
On Thu, 2010-08-19 at 01:13 -0700, Stas Malyshev wrote:
> Hi!
>
> > I was under the impression that, in order for inheritance to provide
> > proper polymorphism, overridden methods should share the parent's method
> > signature, although they can have additional optional arguments.
>
> Your impre
On 19/08/10 09:13, Stas Malyshev wrote:
> Hi!
>
>> I was under the impression that, in order for inheritance to provide
>> proper polymorphism, overridden methods should share the parent's method
>> signature, although they can have additional optional arguments.
>
> Your impression is wrong. Over
Hi!
I was under the impression that, in order for inheritance to provide
proper polymorphism, overridden methods should share the parent's method
signature, although they can have additional optional arguments.
Your impression is wrong. Overriden method should have _compatible_
signature - i.
On 19/08/10 08:51, Stas Malyshev wrote:
> Hi!
>
> I recently noticed this code:
>
> error_reporting(E_ALL | E_STRICT);
>
> class ObjParent {
> public function set($param2 = ''){ }
> }
>
> class ObjChild extends ObjParent {
> public function set(){ }
> }
>
> produces a E_STRICT warning
30 matches
Mail list logo
