Lazare,
I cannot agree with you here. This is exactly why the "protected" keyword
> exists: to provide a black-box interface for class usage through
> inheritance. Yes, this is not automatic and, yes it needs designing, but it
> is certainly not against the principles. If it were, we should remov
2013/5/30 Anthony Ferrara
> Richard et al,
>
>
> On Thu, May 23, 2013 at 5:24 PM, Richard Lynch wrote:
>
> > Consider this common scenario:
> >
> > I use some OOP library, that is a "black box" and I like it that way.
> >
> > As part of the integration, I need to extend one of the library's
> >
Richard et al,
On Thu, May 23, 2013 at 5:24 PM, Richard Lynch wrote:
> Consider this common scenario:
>
> I use some OOP library, that is a "black box" and I like it that way.
>
> As part of the integration, I need to extend one of the library's
> classes:
>
The problem with this entire thread
First, thanks for all the comments!
Responding in-line to myself to address everything so far in this thread:
On Thu, May 23, 2013 4:24 pm, Richard Lynch wrote:
> Consider this common scenario:
>
> I use some OOP library, that is a "black box" and I like it that way.
This was a made-up scenario.
> It can be perfectly ok to allow the lib to be extended and the constructor
> extended/replaced with a compatible one.
Well sure, it's great to override constructors completely. If the lib
authors didn't want you to do that, they should've made it final
(which is what I said they should do now).
>
> This thread arose in response to what is undeniably a bad API
> authoring practice (first allowing full ctor override and later
> breaking BC without fanfare) Why are we letting the authors of
> Richard's library off the hook and putting it on ourselves to develop
> hacks? They obviously screwe
Encouraging call super is still not the right way to go about this. As
I said before, even with the changes proposed, there's no way to
*contractually enforce* the call super pattern in this language.
That's why it is and will remain an antipattern. So all you're doing
is allowing people to more ea
On Fri, May 24, 2013 at 5:32 PM, Ferenc Kovacs wrote:
>
>
>
> On Fri, May 24, 2013 at 5:26 PM, Etienne Kneuss wrote:
>
>> Sure the default implementation would have to be identical to the
>> behavior of not defining one.
>>
>>
> agree
>
>
>> I believe the best way to solve these issues is by hav
On Fri, May 24, 2013 at 5:26 PM, Etienne Kneuss wrote:
> Sure the default implementation would have to be identical to the behavior
> of not defining one.
>
>
agree
> I believe the best way to solve these issues is by having an implicit base
> class.
>
that would also solve the "I want to type
Sure the default implementation would have to be identical to the behavior
of not defining one.
I believe the best way to solve these issues is by having an implicit base
class. To some extent, that means BC breaks though.
On Fri, May 24, 2013 at 5:22 PM, Ferenc Kovacs wrote:
>
> Hi.
>>
>> I'm
> Hi.
>
> I'm not an expert here, so just thinking out loud ...
>
> If a theoretical \PHP\baseclass can have empty __construct()/__destruct(),
> what about the other magic methods?
>
> OK, I suppose cascading some of the magic methods to a parent and having a
> null parent at the very very bottom o
On 24 May 2013 13:11, Ferenc Kovacs wrote:
> On Thu, May 23, 2013 at 11:32 PM, Stas Malyshev >wrote:
>
> > Hi!
> >
> > > Right now, to avoid this situation, you have to do:
> > > if (method_exists(get_parent_class(), '__construct'))
> > > parent::__construct();
> > >
> > > If you don't check for
On Thu, May 23, 2013 at 11:32 PM, Stas Malyshev wrote:
> Hi!
>
> > Right now, to avoid this situation, you have to do:
> > if (method_exists(get_parent_class(), '__construct'))
> > parent::__construct();
> >
> > If you don't check for the method existing, you get:
> > Fatal error: Cannot call cons
> I use some OOP library, that is a "black box" and I like it that way.
Hmm, there's "well-documented, change-controlled, trustable API that
you shouldn't try to work around" and then there's "black box." I'm
not sure the latter ever sounds like a good thing... I've always used
it as a bad word.
Hi!
> Right now, to avoid this situation, you have to do:
> if (method_exists(get_parent_class(), '__construct'))
> parent::__construct();
>
> If you don't check for the method existing, you get:
> Fatal error: Cannot call constructor ...
This makes a lot of sense. I think we also discussed this
Consider this common scenario:
I use some OOP library, that is a "black box" and I like it that way.
As part of the integration, I need to extend one of the library's
classes:
class App_bar extends Library_foo{
function __construct(){
//do whatever I need to do here.
}
}
So I write this
16 matches
Mail list logo
