Hello again.
I think we can condense the issues raised in the thread so far down to:
- What purpose would this feature serve in the face of design/pattern-based
alternatives?
- In what order should the constructor(s) be called?
- How to approach overriding these constructors if necessary?
- How w
> I've been thinking about this for a bit and even if you are right
> about being nice to have a way to call a function always after
> constructor. It could happen. You could have a DB class and in
> constructor the user/pass/host/options and then a separate method for
> init().
But that's not Cal
On Wed, Jul 3, 2013 at 11:10 PM, Sanford Whiteman
wrote:
>
> > Not that it would be an argument but just for understanding: Do you know
> > any scripting language which has this?
>
> Dropping the "scripting" part... IIRC, C++ calls ctors without
> arguments automatically like in my 'sequentialBefo
> Not that it would be an argument but just for understanding: Do you know
> any scripting language which has this?
Dropping the "scripting" part... IIRC, C++ calls ctors without
arguments automatically like in my 'sequentialBefore' napkin sketch.
C# has language-level support for 'sequentialBef
> No, that's why I am asking. Why is it an anti-pattern to call a known
> super constructor?
Guess I'd send you to my comments in the earlier thread as I think I
exhausted my ability to dismantle (advisory a..k.a. "pretty please")
Call Super there. Or "?call super antipattern".
Of course, most ev
On 03.07.2013 20:48, Sanford Whiteman wrote:
>> Most often if I need a super __construct(), I don't need it exactly
>> before or exactly after the bottom constructor but at a specific point
>> where I can setup super's input data and do stuff to its output.
>
> I've most often seen, or reluctantly
> Most often if I need a super __construct(), I don't need it exactly
> before or exactly after the bottom constructor but at a specific point
> where I can setup super's input data and do stuff to its output.
I've most often seen, or reluctantly implemented, the Call Super
antipattern by putting
On 03.07.2013 20:05, Sanford Whiteman wrote:
> a new keyword is problematic, perhaps this same
>> behaviour could be enacted in cases where an inheriting class has a
>> constructor and the base class' constructor is defined as final i.e. rather
>> than causing an error, the final constructor is exe
I suggest you read this recent thread for related commentary.
http://www.serverphorums.com/read.php?7,71
In there, I refer to your proposal as Contractual Call Super and I
find it an interesting concept that helps avoid the "advisory call
super" antipattern.
However --
> If the introdu
For what it's worth, some time ago I prototyped something like that, without
modifying the language, in the form of a "Universal" class that you may
inherit from without defining __contruct/__destruct yourself.
See class definition below. In a using class (herarchy) define static methods
_pre_i
10 matches
Mail list logo
