Page MenuHomePhabricator

ecore: add infrastructure to make it easy to enforce Efl.Loop_Model children lifecycle.
ClosedPublic

Authored by cedric on Feb 1 2019, 4:00 AM.

Diff Detail

Repository
rEFL core/efl
Branch
T7528-devs/cedric/child_noref
Lint
Lint OK
Unit
No Unit Test Coverage
Build Status
Buildable 9432
cedric created this revision.Feb 1 2019, 4:00 AM

At some point you'll need to sit with me and write a tutorial about Models...

So, how is this new method supposed to be used? Every time I call children_slice_get I need to call child_slice_define? That sounds like it could be done automatically.

cedric added a comment.Feb 4 2019, 1:35 PM

At some point you'll need to sit with me and write a tutorial about Models...

So, how is this new method supposed to be used? Every time I call children_slice_get I need to call child_slice_define? That sounds like it could be done automatically.

It is a decision that the Model has to made depending on the lifecycle it expect for its children. Basically if the Model has a lot of potential children, it is better for them to only be alive when a client need them instead of being alive for as long as the parent Model is. For example, Efl.Io.Model child should really only live for when they are actually used by the View, but for Eldbus.Model, the children object can stay alive for as long as the parent as they are very small number actually. So it depends on what the internal of the parent Model (the one that implement children_slice_get) needs.

When that function is called it will automatically destroy the children Model when the only reference left is the parent reference. Enforcing that the Model is alive for as long as the View use them.

OK, I understand the use case. This will need example code at some point.
What this method does is installing a handler so the child models are destroyed when they have no refs besides their parent's, correct?
Then I do not think child_slice_define is a clear enough name...

cedric added a comment.Feb 5 2019, 9:30 AM

OK, I understand the use case. This will need example code at some point.
What this method does is installing a handler so the child models are destroyed when they have no refs besides their parent's, correct?

Indeed.

Then I do not think child_slice_define is a clear enough name...

I know I am terrible at naming things. What do you think of child_selfdestruct ?

What do you think of child_selfdestruct ?

looooooooool but no.

Some suggestions: destroy_if_unused, volatile, force_usage, force_external_usage... all with accompanying good docs :)

cedric added a comment.Feb 7 2019, 1:13 AM

What do you think of child_selfdestruct ?

looooooooool but no.

Some suggestions: destroy_if_unused, volatile, force_usage, force_external_usage... all with accompanying good docs :)

volatile sounds actually good to me. Will update with that.

cedric updated this revision to Diff 19235.Feb 7 2019, 1:57 AM

Rebase and rename.

My bad, volatile is an adjective so it is not suitable as a method name :(
make_volatile?

I would think in that case volatile_make would be the way to go?

cedric updated this revision to Diff 19288.Feb 11 2019, 10:04 AM

Rebase and rename.

segfaultxavi accepted this revision.Feb 21 2019, 12:18 PM
This revision is now accepted and ready to land.Feb 21 2019, 12:18 PM
This revision was automatically updated to reflect the committed changes.