<< §B.1 Paragraphs changed between versions | ↑ Table of Contents ↑ |
§B.2 Additions between versions
(1) Between OTJLD 1.0 and OTJLD 1.1
- §1.2.4.(c):
Role class literal
Made existing feature explicit and introduce new qualified class literal for externalized roles.
- §3.1.(j) and §3.5.(h) :
Inferred callout
New feature.
- §4.6.(a) :
Callin-binding private methods from super classes
Added a necessary restriction.
- §4.9 :
Callin inheritance
Clarified issues that where under-specified or insufficiently explained, specifically:
- §4.10:
Generic replace bindings
Reconcile type safety of replace bindings as introduced in §4.5.(d) with desirable flexibility by using type parameters.
- §7.2.(b) :
Arrays of Confined
Added a necessary restriction.
(2) Between OTJLD 1.1 and OTJLD 1.2
- §1.2.2.(h) :
Externalized creation
Added alternative syntax using value parameter and changed title.
- §1.2.5.(f) :
Imports in role files
Added a missing rule defining the effect of imports in role files.
- §1.3.1.(c) :
@Override annotation for roles
The regular
@Override
annotation (Java ≥5) has been extended to apply to role classes, too. - §1.3.1.(k) :
Covariant return types
Necessary constraint for covariant return types in the presence of both implicit and explicit inheritance.
- §2.1.2.(c) :
Binding to final base class
It has been added that binding to a final base class is now considered as decapsulation, too.
- §2.2.(f) :
Ambiguous lowering
A diagnostic has been added to detect situations where lowering might be intended but fails because the declared type is
java.lang.Object
, which makes a potential lowering translation unnecessary and thus ambiguous. - §2.3.2.(e) :
Generic declared lifting
Support passing unrelated base types into the same method with declared lifting.
- §2.6.(g) :
Decapsulation via base reference
Extended applicability of decapsulation to two more positions.
- §4.3.(f) :
Base super call
Support base calls directly to the super version of the bound base method, thus bypassing both the exact bound base method and also any further callins relating to this base method or its super version.
- §5.4.(b) :
Side-effects in guard predicates
Migrate previous note about a future feature to a regular paragraph.
- §5.4.(c) :
Exceptions in guard predicates
Clarify the effect of exceptions thrown from a guard predicate.
- §6.2.(d) :
LiftingVetoException
Added documentation for the mostly internal
LiftingVetoException
and how it could actually be used in client code. - §6.2.(e) :
Role migration
Added two interfaces to add migration capabilities to a role class.
(3) Between OTJLD 1.2 and OTJLD 1.3
- §2.1.1 :
Binding roles to base interfaces
The implementation limitation mentioned in §2.1.1 has been mostly removed.
- §2.3.1.(d) :
Fine-tuning role instantiation
An annotation has been defined for modifying the semantics of lifting in order to improve performance. Also a new section has been added as §6.3 to summarize the annotation types defined in this document.
- §2.3.5 :
Consequences of lifting problems
After §2.3.4 has clarified that
LiftingFailedException
(§6.2.(d)) is indeed a checked exception, a subsection has been added defining the consequences of this exception in various program situations. - §3.1.(k) :
Callout to generic method
Added a rule on how a callout binding may refer to a generic base method.
- §4.1.(b) :
Callin binding in "unliftable" role
Callin bindings can now be defined even in "unliftable" roles.
- §4.1.(h) :
Binding to team methods
before
andafter
callin bindings can now bind to methods of an enclosing class, too. - §4.8.(d) :
Order when merging precedence declarations
Clarified how several precedence declarations are merged, which was underspecified, because the C3 algorithm needs ordered inputs, but this order was not specified.
- §4.10.(e) :
Propagating type parameters in callin bindings
In addition to capturing covariant return types, a callin binding may also declared type parameters in order to propagate genericity from its base method to the role method.
- §5.3.(d) :
Configuring implicit activation
Mechanisms have been added for configuring implicit team activation. The default has been changed to not apply implicit activation. A corresponding note has also been added to §5.3
- §9.2.1.(a) :
Instance constrained type parameter
Type anchors can now be applied to type parameters, too, thus expressing a new kind of constraint on the type parameter.
<< §B.1 Paragraphs changed between versions | ↑ Table of Contents ↑ |