<< §B.1.(2) Between OTJLD 1.1 and OTJLD 1.2 | ↑ Table of Contents ↑ |
§B.1.(3) Between OTJLD 1.2 and OTJLD 1.3
- §1.2.4.(c) :
Syntax for role class literals
Previously, the syntax
R<@t>.class
was not supported. This restriction has been removed. - §1.3 :
Teams extending non-team classes
Previously,
org.objectteams.Team
was the super class of all team classes. As a consequence a team could not extend a non-team class. This restriction has been removed by introducing a new super-type of all teams, the interfaceorg.objectteams.ITeam
. This change also affects some paragraphs in §6 as members have been moved to the new interface. - §1.5.(e) :
Precedence among different implicit supers
Corrected an inconsistency in the rules for precedence among different supers: The primary rule has always been that implicit inheritance binds stronger than explicit inheritance, however, for precedence among different implicit supers a different rule was defined.
This has been changed such that different implicit supers are prioritized by the precedence of their enclosing teams, such that a role from an implicit super team is closer related than a role from an explicit super team. - §2.1.2.(b) :
Relaxed the rule against base class circularity
Base class circularity as defined in §2.1.2.(b) is no longer an error but as a configurable warning. However, in the presence of base class circularity, neither callouts (§3.1.(a)) nor base constructor calls (§2.4.2) are allowed.
- §2.3.4 :
Changed handling of role binding ambiguities
A definite binding ambiguity is no longer a (suppressable) compiler error, but is signaled by the need to declare
org.objectteams.LiftingFailedException
. This way diagnostics could be moved from rather unspecific locations in the team towards those applications that could suffer at runtime from a lifting failure. While it is generally not recommended to ignore anyLiftingFailedException
catching this exception may still make sense in a few corner cases mentioned in §2.3.4.(b). - §4.4.(c) :
Further restrict result mapping in after callin bindings
Clarify that
after
callin bindings cannot use the->
token to map a result value. - §4.8.(a) :
Precedence declarations affecting
after
callin bindings.While previously the effect of precedence declarations was underspecified it has been defined that the order of elements in a precedence declaration affects their priority similar to §5.1. This implies that the execution order for
after
bindings is now reversed compared to the previous implementation. In order to visualize this in the program it is now mandatory to mark precedence declarations for after bindings with the keywordafter
. - §4.10, §4.10.(a) :
Generic callin bindings
Minor changes to give room for new paragraph §4.10.(e).
- §5.4.1.(a) :
Scope of regular binding guard
Removed an erroneous sentence about the special identifier
result
in a regular method binding guard. Since parameter mappings are applied before evaluating the guard, the result value can be accessed through a result mapping (§4.4.(c)). Furthermore, the sentence actually confused base and role sides. - §A.3.2, §A.3.3 :
Syntax: generic method bindings
The location of possible type parameters in a method binding has been made explicit.
<< §B.1.(2) Between OTJLD 1.1 and OTJLD 1.2 | ↑ Table of Contents ↑ |