Page MenuHomePhabricator

efl.io.closer
Open, TODOPublic

Description

| | |mixin Efl.Io.Closer
| | |├ (P) closed
| | |├ (P) close_on_exec
| | |├ (P) close_on_invalidate
| | |├ (M) close
| | |├ (E) closed

Details

zmike created this task.Wed, Jan 9, 10:20 AM
zmike triaged this task as TODO priority.

Upon closer examination Efl.Io.Closer is a mixin and not an interface because it implements ONE method.
You can close something by calling the interface method close(), or by setting the property closed to true.
closed_set() is implemented by the mixin, by calling the virtual close() method.
I think we can ditch the closed property and turn Efl.Ui.Closer into a regular interface instead of a mixin.

Will provide a patch.

After D7570, its hierarchy looks like this (notice only the type has changed):

interface Efl.Io.Closer
├ (P) closed
├ (P) close_on_exec
├ (P) close_on_invalidate
├ (M) close
├ (E) closed
zmike added a comment.Thu, Jan 10, 5:28 AM

This seems like a sensible change; having both a method and a property_set which do the same thing seems redundant.

zmike moved this task from Backlog to Evaluating on the efl: api board.Thu, Jan 10, 10:08 AM

Totally agreed. So we can consider this stable (After D7570 lands)?

I would think so. @segfaultxavi can you propose a patch that make this a stable API?

We need to evaluate first if src/lib/eo/efl_object.eo and src/lib/efl/interfaces/efl_types.eot are stable too, because this class depends on them.
If they are stable, they need to get out of the #ifdef EFL_BETA_API_SUPPORT in src/lib/eo/Eo.h too.

zmike added a comment.Mon, Jan 14, 7:12 AM

It's fine to decide that this is stable and mark it as such; we can come back to eo deps later.

I meant that if we do not make first the changes in Eo.h, the changes in Efl.h do not build (that's why I provide both in this patch), because of moving the #includes up in the list.

Sure, but there's still no harm in putting up a patch and moving the workboard along.

I'm lost now. What are you proposing exactly?

This seems ok from C# (after the interface patch).

Maybe we could also remove the @pure_virtual tags from the now interface, as interface methods are implied to be implemented anyway.

@lauromoura You're right, that was an oversight. Updated the patch in D7570.

Maybe we could also remove the @pure_virtual tags from the now interface, as interface methods are implied to be implemented anyway.

https://phab.enlightenment.org/T7632

We should not allow this in eo at all.