Hi,
the example has a little problem, M is available to C with or without
implementation in B, since its declared on A. The detail that B
implements it does not really matter here.
As a set of rule i would say that we could go with something like :
- Must keep the ordering and elements in the chain of inheritance as
they are, the only thing that we can do is injecting a new class between
inheritance levels
- The set of APIs on a class (due to implementing interfaces and
declaring API) must stay the same, and we can only extend that set, but
never delete any API (as long as it has been stable)
- implementation details who is implementing which API does not matter
to stability, the important part is where it is declared, and that this
place stays.
- A declaration of stable API must stay as it is, the types & the return
type must not be changed.
(When i am speaking here of a class, i mean class/interface/abstract/mixin)
Greetings,
bu5hm4n
On 9/6/19 3:32 PM, Mike Blumenkrantz wrote:
Hi,
This is a mail for the purpose of formalizing a policy as it relates the
the "stability" of relationships between classes in EFL. With EFL 1.23,
Eolian is expected to become stable, which will mean that .eo files are
effectively stable. There is not, however, a formal definition of what
"stable" means in this context.
As an example, consider the following case where:
* classes 'A', 'B', 'C' where 'C extends B' and 'B extends A'
* 'B' implements method 'M' from 'A'
Should having 'M' available to 'C' from its inheritance by 'B' be
considered "stable" across releases, or can this be changed? Similarly, is
this inheritance chain "stable", or can that be changed?
This may seem like a clear-cut scenario to some, but it's important that a
global policy is decided upon in advance of the release so that it can be
documented and expectations can be set both for EFL itself as well as its
users.
I've created a tracking ticket (https://phab.enlightenment.org/T8209) where
the policy decision will be recorded for historical purposes.
Regards,
Mike
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
