↑ Table of Contents ↑ | §B.2 Additions between versions >> |
§B.1 Paragraphs changed between versions
(1) Between OTJLD 1.0 and OTJLD 1.1
- §3.2.(a) :
Parameter mappings
Disallow parameter mappings in a role interface.
- §4.5.(d) :
Replace bindings
Disallow unsafe use of polymorphism and primitive type conversions.
- §6.1.(a) :
Signatures of reflective methods
Made two methods generic so that return values can be used without the need of casting.
- §7.2 :
Confined roles
Improved explanation.
(2) Between OTJLD 1.1 and OTJLD 1.2
- §1.2.1.(e):
Visibility of role features
Clarification has been added that a role can always access all the features that its enclosing team has access to.
- §2.1.2.(e):
Generic roles/bases
Relaxed the rules about generic bound roles. This change also subsumes what previously was a specific restriction in §4.1.(b).
- §3.1.(i) and §3.5.(f):
Visibility of shorthand callout
A role method defined by a shorthand callout binding can now specify a visibility modifier (see also §A.3.2), otherwise it inherits the visibility modifier of it's bound base method/field.
- §3.1.(j) and §3.5.(h):
Visibility of inferred callout
Role methods inferred as a callout binding are either
public
(inferred via interface) orprivate
inferred from self call / field access. - §3.5.(h):
No explicit use of inferred callout to field
Clarification has been added that an accessor method generated for an inferred callout to field can not be explicitly invoked.
- §4.1.(b):
No callin in generic role
A restriction has been made explicit that a generic role cannot define callin bindings.
- §4.2.(d) :
Callin methods
Slightly rephrased and extended the rule to make explicit that a callin method can indeed be intercepted using a second level callin binding.
- §6.1.(a) :
Reflective methods
getAllRoles
More precision: answer only bound roles.
(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. - §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.
↑ Table of Contents ↑ | §B.2 Additions between versions >> |