Community
Participate
Working Groups
(originally from http://trac.objectteams.org/ot/ticket/113) In test 9.2.1-otjld-has-role-method-5c2, when defining the method binding in super-role R, the compiler reports: Callin mapping not allowed here, because lifting to role Team921hrm5c2.R is not possible due to a reported binding ambiguity (OTJLD 4.1(b)). It should be checked whether this restriction can be removed. The method binding would have to be propagated down to all non-ambiguous sub-roles, so that the effect would be the same as what is currently written in the mentioned test. ----- today's analysis: just omitting the error would indeed lead to code that throws a LiftingFailedException, because the callin wrapper tries to lift to the super role, even if a sub-role exists. Possible actions: - the lift method could be made smarter to include a cache lookup even if a binding ambiguity has been detected. - errors regarding OTJLD 2.3.4(b) could be made configurable to admit the case where lifting is indeed decided by an existing role instance. This issue should be documented in 2.3.4(a,b) and 4.1(b)
Created attachment 171473 [details] OTJLD additions These additions to the OTJLD define how the error message in question can be configured/suppressed (using token "def-bind-ambiguity"). 2.3.4(b) talks about the root error, 4.1(b) about how this can be leveraged to define callin bindings even in an "unliftable" role.
Created attachment 171474 [details] implementation This patch implements: - best effort lifting: even for ambiguous roles still check the cache - always generate callin wrappers, even if role has binding ambiguity - new configurable irritant DefiniteBindingAmbiguity (deliberately no UI-configurability - should always be individually checked) Corresponding tests can be found in test73M_ambiguousBinding1() and test73M_ambiguousBinding2(), which indeed test for both corner cases mentioned in OTJLD 2.3.4(b).
Implementation has been committed as r440.
Two small fups have been committed in r442,r443.
Verified for M4 using build 201006111053.