1.8 KiB
16. Dispatch, override et modificateurs
16.1 Ordre canonique — V1 REQUIS — FIGÉ
Ordre des modificateurs :
visibility
-> safety
-> linkage / ABI
-> type / dispatch modifiers
-> override
-> declaration kind
Puis :
Name<...>
-> extends ...
-> implements ...
extends et implements sont des clauses après le nom, pas des modificateurs.
Exemples :
public final class User
public open class Service
public abstract class Base
public unsafe extern "C" union NativeValue
protected open method calculate(...)
protected override method calculate(...)
protected final override method calculate(...)
Les ordres alternatifs sont des erreurs syntaxiques même s'ils seraient théoriquement compréhensibles.
16.2 Méthodes overridables — V1 REQUIS — FIGÉ
Une méthode nouvellement déclarée n'est pas overridable par défaut.
Elle doit être explicitement :
open method
ou :
abstract method
Un descendant utilise :
override method
Pour fermer ensuite la chaîne :
final override method
final method sur une nouvelle méthode n'apporte rien et n'est pas nécessaire : l'absence de open suffit.
Même modèle pour clsmethod si elle participe au dispatch de classe.
16.3 Visibilité d'override — V1 REQUIS — FIGÉ
Un override conserve exactement la visibilité du contrat hérité.
Pas d'élargissement ni de réduction implicite.
Une exposition plus large nécessite un wrapper explicite.
16.4 protected — V1 REQUIS — FIGÉ EN PRINCIPE
protected existe uniquement dans le modèle d'héritage de classe et signifie « accessible depuis les classes dérivées » en plus de la classe déclaratrice.
Les détails d'accès via une autre instance d'une classe dérivée doivent être figés dans les règles finales de résolution membre.