Protected init

[mvorisek]

Documented also to be not called directly, but quite large breaking change

How to migrate your code?

replace public function init() with protected function init()
and ->init() with ->invokeInit()

[georgehristov]

It is called by the container object:

core/src/CollectionTrait.php

Line 68 in 6d40e4d

$item->init();

core/src/ContainerTrait.php

Line 71 in 6d40e4d

$obj->init();

[mvorisek]

It is called by the container object:

yes, and also in ui and data... I prepared fixes

[mvorisek]

init() should definitely be not public

sometimes (at least in ui) we need before/after init - now this can be done easily by overriding invokeInit()

@georgehristov @DarkSide666 wdyt?

[georgehristov]

What is the benefit of protecting init and then exposing it with another method?

[mvorisek]

bc9fe4a

there are a lot of situations when you need before/after init method - I was thinking about hooks, but this is fine as you can override invokeInit() - this is needed when init() itself is extended, which is very ofter in ui

and by making init() protected we can ensure it is (without hacking) not called directly

[georgehristov]

Yes, I agree with that. Setting View::$model for instance needs to be done afterInit and not during init.
To follow common naming paterns (as in atk4/data) maybe we can use init, doInit (instead of invokeInit, init)?
So you keep init public but we move the actual routine under protected doInit. It will be no BC break then I believe

[mvorisek]

To follow common naming paterns (as in atk4/data) maybe we can use init, doInit (instead of invokeInit, init)?

doInit is horrible

there are two uses and they do not invoke!, they process the operation (delete) after beforeDel and before afterDel:

So you keep init public but we move the actual routine under protected doInit. It will be no BC break then I believe

Impossible, the init method must be protected and not called directly :)

[georgehristov]

I was talking about the atk4/data#690 where the actual operations are performed in doXx methods.

Impossible, the init method must be protected and not called directly :)

But we call directly the invokeInit? The matter is only of naming, mostly for consistency.

[mvorisek]

doXxx there is fine in Sql sense (ie. do/send query)

here we keep init as standard method to implement

But we call directly the invokeInit?

I understand your point - there are some uses, for easy migration, I propose to keep "some" method and keep it public, in optimal world, this method should never be called by used.

[mvorisek]

FYI: checked for every instance/call, but it is fast: +0.5% of total testing time for atk4/ui where used heavily

[DarkSide666]

In my opinion this is huge breaking change and almost without any advantage.
init() now will be protected - so what? What's the advantage?
Also all this reflection magic just adds complexity of code and ... for what?

[georgehristov]

The only thing that needs to be adressed is the afterInit functionality which we need to introduce.

For instane in UI View class we call View::setModel within the init method which is not correct and this method should be called after init completed. Call to setModel is at the end of View::init but all classes that extend it add more statements.
So this does not work as expected for Crud for example as routine in setModel expects some properties to be initiated in init but they are not as setModel is called at the end of View initiation which is the beginning of initiation of Crud.

[mvorisek]

@georgehristov let's go on Discord and discuss the final version, I need this to be merged asap

[DarkSide666]

OK I agree :)