Absolutely, M from B/A should be considered to keep compatibility. Otherwise it's abi break.
On Mon, Sep 9, 2019 at 4:53 AM Carsten Haitzler <[email protected]> wrote: > On Fri, 6 Sep 2019 09:32:53 -0400 Mike Blumenkrantz > <[email protected]> said: > > > 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. > > just to be clear we're talking eolian and eo file format being stable and > not > OUR *.eo files and classes in efl... right? > > > 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 should be stable. if it was not we'd have an abi break, so in future > this > has to be considered stable. it can change from being overridden to not and > vice-versa, but the existence of a method (or in c the fact that class > function > works on that object type) should be considered stable. same with events > that > are inherited... > > that's my take. > > > 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 > > > > > -- > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > Carsten Haitzler - [email protected] > > > > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Regards, Hermet _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
