New feature: sequential constructors View as Markdown

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_init, _post_init, _pre_exit and _post_exit. They will receive the
instance as their sole argument. __construct first calls _pre_init up the
inheritance chain, then _post_init on the way back down; likewise __destruct
calls _pre_exit and _post_exit

In the current form it is only moderately useful, because it doesn't support
constructor arguments. These throw up the question of how to pass them to the
"sequential" constructors, and what these would then usefully be able to do
with them...

best regards
Patrick

class Universal {

    static private $_universal_pre_inits = [];
    static private $_universal_post_inits = [];
    static private $_universal_pre_exits = [];
    static private $_universal_post_exits = [];

    public function __construct() {
            $class = get_class($this);
            $initclass = $class.'°universal_init';
            if (!class_exists($initclass, false))
                    Universal::_universal_inits_and_exits($class);
            $initclass::_universal_init($this);
    }

    public function __destruct() {
            $initclass = get_class($this).'°universal_init';
            $initclass::_universal_exit($this);
    }

    final protected function _universal_inits_and_exits($class) {
            $pre_inits = [];
            $post_inits = [];
            $pre_exits = [];
            $post_exits = [];
            $c = new ReflectionClass($class);
            try {
                    $m = $c->getMethod('_pre_init');
                    if ($m->class == $class)
                            $pre_inits[] = [ $class, '_pre_init' ];
                    $m = $c->getMethod('_pre_exit');
                    if ($m->class == $class)
                            $pre_exits[] = [ $class, '_pre_exit' ];
            } catch (Exception $e) {};

            $parent = get_parent_class($class);
            if ($parent && $parent != 'Universal') {
                    if (!class_exists($parent.'°universal_init', false))
                            Universal::_universal_inits_and_exits($parent);
                    $pre_inits = array_merge($pre_inits, self::

$_universal_pre_inits[$parent]);
$pre_exits = array_merge($pre_exits, self::
$_universal_pre_exits[$parent]);
$post_inits = array_merge($post_inits, self::
$_universal_post_inits[$parent]);
$post_exits = array_merge($post_exits, self::
$_universal_post_exits[$parent]);
}

            try {
                    $m = $c->getMethod('_post_init');
                    if ($m->class == $class)
                            $post_inits[] = [ $class, '_post_init' ];
                    $m = $c->getMethod('_post_exit');
                    if ($m->class == $class)
                            $post_exits[] = [ $class, '_post_exit' ];
            } catch (Exception $e) {};

            self::$_universal_pre_inits[$class] = $pre_inits;
            self::$_universal_pre_exits[$class] = $pre_exits;
            self::$_universal_post_inits[$class] = $post_inits;
            self::$_universal_post_exits[$class] = $post_exits;

            $code = "class {$class}°universal_init extends {$class}{";
            $code .= 'static protected function _universal_init($o){';
            foreach (array_merge($pre_inits, $post_inits) as $init)
                    $code .= "{$init[0]}::{$init[1]}(\$o);";
            $code .= '} static protected function _universal_exit($o){';
            foreach (array_merge($pre_exits, $post_exits) as $exit)
                    $code .= "{$exit[0]}::{$exit[1]}(\$o);";
            $code .= '}}';
            eval($code);
    }

}
On Wednesday 03 July 2013 13:45:57 Terence Copestake wrote:

Hello, all.

On one or two occasions I've encountered a problem when designing a base
class, where I wish to implement important set-up functionality in the
constructor, but am limited in how to ensure that the base constructor
functionality is unmolested whilst not restricting any inheriting classes
in their use of a constructor, as would be the case when using the final
keyword. I also don't feel 100% comfortable trusting the inheriting class
to call the parent constructor.

The idea I'm presenting for discussion here is to have some kind of
(keyword-driven?) hierarchy for constructors, whereby it's possible to have
for example sequential constructors, using syntax similar to:

... public sequential function __construct($ ...

In this scenario, constructors defined as sequential are, as the name
implies, called in sequence.

If the introduction of 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 executed first, followed by
any other constructors in the hierarchy.

If this keyword is introduced, perhaps it this idea could also be expanded
to allow for sequential methods in general, which would behave similarly -
and may be a gateway to function overloading (or similar behaviour).

I'm open to people pointing out design flaws/implementation difficulties
with this; pull no punches.

Thanks.

I suggest you read this recent thread for related commentary.

http://www.serverphorums.com/read.php?7,712222

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 introduction of 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 executed first, followed by
any other constructors in the hierarchy.

-- this is a horrible idea. final has distinct semantic meaning. It
means "cannot override." It doesn't mean "overrideable, but we'll call
any/all supers before/after we run yours." It's a BC break.
Fuggedaboutit.

The feature you want isn't in the language -- maybe it should be --
and you can't change the meaning of existing keywords.

-- S.