↑ 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.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 >> |