Void-safe en Eiffel

Copyright 2012, Group S
Benoît Marchal, Paul-Georges Crismer
@declencheur @pgcrismer

Cette présentation est distribuée sous licence CC-BY
Pour les conditions d’utilisation, consulter
http://creativecommons.org/licenses/by/2.0/be/

Agenda

Qu’est-ce le Void-safe ?
Nouveaux éléments de langage
En pratique
Nouveaux projets
Conversion d’un projet

Heu… sérieusement :-)

durant l’exécution d’une application, une référence est
soit attachée à un objet
create a_domain.make
soit Void
a_domain := Void

Banal

synonymes dans tous les langages
SQL, JavaScript, Java, C# : null
Lisp, Pascal : nil
VB : nothing
C/C++ : Ø ou null

Mais
l’appel sur une référence non attachée/void
erreur d’exécution
plus fréquent dans un langage orienté-objet
les objets sont accessibles via des références
que dans un langage procédural
où (hormis C) les pointeurs étaient moins utilisés

Difﬁcile à trouver
évidemment, on n’écrit pas
Void.do_something
create a_domain.make -- a_domain attachée
a_range := Void -- a_range détachée
a_space.lots_of_complex_stuﬀ
a_space… heu… joker !

Similaire à ÷Ø
en calcul sur des entiers
on a besoin du zéro
on a besoin de diviser des entiers
mais il ne faut jamais diviser par zéro
c’est une erreur à l’exécution
mais… plus d’appels sur références que de divisions

De même, Void

Void
indispensable
source d’erreur diﬃcile à détecter
références fréquentes dans un système orienté-objet

A propos…
appel sur Void déclenche une exception
qu’on pourrait intercepter
mais il est plus simple de tester la référence
d’où les innombrables assertions
a_param /= Void
et le bogue courant c’est d’oublier un test

Avoid a void
“That case occurs in system-oriented parts of
programs, typically in libraries that implement
fundamental data structures in the more application-
oriented parts of a program, void references are
generally unnecessary.
[…] conﬁne void references to speciﬁc parts of a
system, largely preserving the application-oriented
layers from having to worry about the issues [of void
references]”

Concrètement
owner
ACCOUNT: 123 PERSON: Jack

owner
ACCOUNT: 345 PERSON: John

owner
ACCOUNT: 567

Void ici signiﬁe
“je ne le connais pas.”

Et pourtant

owner
is_nogood: False

owner
is_nogood: False

owner
ACCOUNT: 567 PERSON: Unknown
is_nogood: True

Ou encore
owner
ACCOUNT: 123 REAL_PERSON: Jack
owner
ACCOUNT: 345 REAL_PERSON: John
owner
ACCOUNT: 567 UNKNOWN_PERSON

<<deferred>>
PERSON

REAL_PERSON UNKNOWN_PERSON

Voire même
owner
owner
owner

{NONE}
unknown_person
SHARED_UNKNOWN_PERSON
Shared_unknown: PERSON
is_unknown(person: PERSON): boolean

A propos du SQL Null
norme ISO : information manquante ou non applicable
complexe (logique à 3 valeurs, join,…)
mais il ne s’agit pas d’une référence, pas d’appel
souvent traduit par une référence détachable en Eiﬀel
sans doute pas la meilleure représentation
nous verrons quelques patterns alternatifs

Donc, Void

indispensable
source d’erreur diﬃcile à détecter
appel sur une référence à Void
fréquent dans un système orienté-objet
à limiter aux parties techniques de l’application

Void safety
renforcer le contrôle des types de référence
attached
detachable
cas particulier, pour les aspects techniques
certiﬁed attachment patterns
garantie du compilateur : plus d’appels sur Void

CAP
transforme un référence détachable en attachée
CAP de base
x.f(…) est void-safe si
x est un paramètre ou une variable locale
dans la portée d’un test d’attachement de x
n’est pas précédé par une assignation à x

Exemple de CAP

local
* name: detachable STRING
do
* -- …
* if name /= Void then
* * name.append ("something else")
* end
end

Erreur VEVI

Variable is not properly set.
local
* text: attached STRING
do
* text.append (" or something")
end

Une solution possible

local
do
* text := "John"
* text.append (" or something")
end

Erreur VUTA

Target of the Object_call is not attached.
local
do
* -- …
* name.append (" or something")
end


local
do
* -- …
* * name.append (" or something")
* end
end

Erreur VUAR
Non-compatible actual parameter in feature call.
local
do
* text := "nothing"
* -- …
* text.append (name)
end

local
do
* text := "nothing"
* -- …
* * text.append (name)
* end
end

Conﬁgurer le projet

1
2 3
4

Conﬁgurer le projet (bis)

5

Conﬁgurer le projet (ter)

6

créer un projet “exo_vs”, sans le compiler

full-class checking? true

void safety: Complete void-safe

syntax: standard syntax

are types attached by default? true

base library: …base-safe.ecf

precompiled base: …base-safe.ecf

Enoncé
par clarté, on indique explicitement attached/detachable
normalement, on n’indique que detachable
complétez deux routines
pour les rendre void-safe et compiler :-)
notez que ce n’est pas la même erreur
bonus : pourquoi ?

Attaché

do_attached
* local
* * queen: attached STRING
* do
* * queen.mirror
* * print (queen)
* end

Détaché

do_detachable (language: detachable STRING)
* do
* * language.append (" is void-safe")
* * print (language)
* end

Proposition de solution

do_attached
* local
* * queen: attached STRING
* do
* * queen := "etihW wonS"
* * queen.mirror
* * print (queen)
* end

Proposition de solution

do_detachable (language: detachable STRING)
* do
* * if language /= Void then
* * * language.append (" is void-safe")
* * * print (language)
* * end
* end

LANGAGE
Nouvelles constructions

Un faux problème ?
pré-conditions de type /= Void assure déjà la sécurité
oui, pour du code existant
mais pour du nouveau code, réduit l’eﬀort
moins à écrire
moins de bogues
augmente la lisibilité

En tous petits caractères
update_flag (a_document, a_file : STRING ;
a_secretary : SELECT_CLASS)
* require
lisible *? a_document_not_void : a_document /= Void
*
* * a_file_not_void : a_file /= Void
* * a_file_in_list : has_file (a_file)
* * a_secretary_not_void : a_secretary /= Void
* do
* * -- …
* end

Contrats logiciels

dans le contrat, on trouve
assertions métier, sémantiquement riches
a_file_in_list : has_file (a_file)
noyées dans… de la technique, un faux void-safe
a_file_not_void : a_file /= Void

Redonner de la lisibilité

update_flag (a_document, a_file : STRING ;
a_secretary : SELECT_CLASS)
* require
* * a_file_in_list : has_file (a_file)
* do
* * -- …
* end

Bénéﬁces

délègue au compilateur les considérations techniques
moins de code à écrire, déboguer, etc.
sécurité accrue, par rapport aux préconditions
une vraie documentation lisible et riche
maintenance, reprise du code simpliﬁée

4 objectifs

statique : vériﬁable à la compilation
général : applicable à tous les types
simple : à comprendre et raisonnable à implémenter
compatible : avec le langage et les applications
en pratique, ce n’est que partiel, il faut porter

Types attachés
qualiﬁe l’attachement d’un type : attached/detachable
Void n’est permis que pour les références détachables
right: detachable LINKABLE[G]
attached est la valeur par défaut, on ne l’écrit pas
vériﬁer les paramètres du projet !
attention à l’ancien code, c’est un changement…

Un choix logique
local
do
* text := "nothing" mais inverse
* -- … d ’aujourd’hui
* * text.append (name)
* end
end

Assignation
l’assignation préserve le caractère attaché
assigner un type attaché ou un paramètre attaché
uniquement depuis une référence attachée
text := "nothing"
if a_detachable /= Void then
* text := a_detachable
end

Initialisation

par défaut, une référence est initialisée à Void
il faut donner une valeur acceptable (erreur VEVI)
une variable doit avoir une valeur acceptable
variable locale, dans le corps de la routine
attribut, via le constructeur

CAP

certiﬁed attachment pattern
assurer la compatibilité
en intégrant des pratiques courantes
si elles sont sûres
en particulier, le test d’une variable locale /= Void

Autre exemple de CAP
local
* current: detachable LIST_ITEM
* -- …
from
* current := ﬁrst_element
until
* current = Void or else current.item.is_equal (sought)
loop
* current := l.right
end

CAP et pré-condition

do_detachable (name: detachable STRING)
* require
* * name_attached: name /= Void
* do
* * name.append (" is famous")
* * print (text)
* end

CAP et attributs
if x /= Void then
* do_something
* x.do_something_else
end
n’est pas void-safe si x est un attribut
multithreading : modiﬁcation entre test et appel
monothread: do_something modiﬁe l’attribut

Stable
impossible d’assigner Void à un attribut stable
donc une fois attaché, il le reste
stable x: detachable TYPE
permet d’utiliser le CAP avec des attributs
puisqu’il ne peut être détaché après le test…
sucre syntaxique pour une conversion

Test d’objet
if attached {TYPE} expression as a_local then
* -- …
* a_local.do_something
end
teste le type de l’expression et l’assigne à local
remplace la tentative d’assignation ?=
restreint la portée de la variable locale au test

Versions simpliﬁées
if attached expression as local then
* -- …
* local.do_something
end
if attached local then
* -- …
* local.do_something
end

Et si on le “sait” ?
e.g., en combinant diverses pré-conditions
invariant : error implies attached message
report_error
* require
* * error_set: error
* do
* * -- message est attaché… pas pour le compilateur
* end

Check… then… plus lisible
if attached message as a_message then
* a_message.do_something
else
* -- que mettre ici ? une erreur ?
end
check attached message as a_message then
* a_message.do_something
end

Générique

un paramètre générique est-il attaché ou non ?
si nécessaire, on le précise lors de la déclaration
une déclaration de contrainte habituelle
class GENERIC_CLASS[T -> attached ANY]

Tableaux
les éléments d’un tableau sont initialisés à… Void
acceptable pour un type détachable
inacceptable pour un type attaché
make_ﬁlled (low, high: INTEGER; value: G)
make_empty et on fait grossir le tableau
si les indices progressent 1 par 1

Full class checking
PERSON make_with_names (a_first, a_last: STRING)
* do
make_with_names (a_first, a_last) * * first_name := a_first
first_name: STRING * * last_name := a_last
last_name: STRING * end

make
TAXI_DRIVER * -- first_name & last_name ne sont pas attachés !
* do
make * * create taxi.make
taxi: CAR " end

Obligatoire en Void-safe
mais automatique en Eiffel 7.x
re-vérifie les features héritées dans le descendant
dans l’exemple, erreur VEVI
make_with_names (a_first, a_last: STRING)
* do
* * Precursor (a_first, a_last)
* * create taxi.make
* end

Void-safety
No void safety
compilation à l’ancienne, pas de contrôle
On demand void safety
vériﬁe l’initialisation des références attachées
Complete void safety
applique tous les contrôles

Void control
Void safety
le compilateur garantit l’absence d’appel sur Void
Void confidence
le programmeur a confiance dans son code
par contrat et/ou “On demand void safe”
choix réaliste et suffisant ?

Etat des lieux, Group S
2012
EiﬀelBase : Void-safe
EWF : Void-safe
ECLI/EPOM : Void-conﬁdent
Gobo : pas encore Void-safe (en cours)
EPOSIX : pas Void-safe

Donc, en pratique

on peut viser la void conﬁdence
au moins jusqu’à la migration de Gobo
remplacer EPOSIX par EiﬀelBase, si possible
le projet doit être “On demand Void-safe”
et utiliser les nouveaux ECF

Syntax
Obsolete/transitional/standard syntax
note remplace indexing comme mot-clé
Provisional syntax
éléments en cours de normalisation
recommendation : Standard syntax
ISO 25436/ECMA 367

Type attachment
attached ➡ detachable
Are types attached by default?
True, pour tout nouveau projet
conseillé pour un nouveau projet
False préserve l’ancien comportement
réservé aux conversions complexes

De nouvelles habitudes
le void-safe est un outil
comme le système de type
comme les contrats logiciels
comme l’encapsulation
pour construire des systèmes plus robustes
Void-safe n’est pas un but en soi

Dans le code applicatif
minimiser les références détachables
pas un but de les éradiquer mais un moyen
mais il faut… se défaire de mauvaises habitudes
Void veut-il dire quelque chose : quoi ?
peut-on l’exprimer de façon plus claire ?
quelques patterns pour nous aider

Pattern du zéro pointé 1

took
CAMERA ARRAY[PHOTO]
count = 54
1

54

PHOTO

took
CAMERA ARRAY[PHOTO]
count = 0

Référence détachable
à éviter

took
CAMERA

Void ici signiﬁe
pas de photo donc zéro photo
soyons plus explicite encore

si la référence est détachable
if attached took as a_took then
* accross a_took as i loop i.item.something end
end
si la référence est attachée
accross took as i loop i.item.something end
toujours aussi correct mais plus lisible
zéro passage dans la boucle…

Quand l’appliquer ?

relation dont la cardinalité Ø-n
structure (tableau, liste,…), vide pour Ø
attention aux “faux null”
par exemple, dans la BD, la foreign key est nulle

Pattern de la fourmi 2

inherit ANY redeﬁne default_create end

create default_create

feature {NONE} -- Constructor
* default_create
* * do
* * * Precursor
* * * create text.make_empty
* * end

Référence attachée
lazy initialisation
on accepte l’initialisation par défaut (Void)
donc la référence doit être détachable
if attached text as a_text then à éviter
* a_text.append (something)
end
habituellement c’est une optimisation à priori

Un compromis…
Calcul (et donc bogues) Mémoire

Et, bien entendu…
make (a_text: STRING)
* do
* * default_create
* * text.copy (a_text)
* end
make_as_mirror (a_text: STRING)
* do
* * default_create
* * text.copy (a_text.mirrored)
* end

Choisir le défaut
chaîne vide
message informatif
“Nom inconnu”
données de test
“4200 0000 0000 0000”
voir aussi le pattern Iznogoud

Et pour les invariants…
confus, on n’est pas tenté de l’écrire ou de le lire
invariant
* valid: card /= Void implies is_valid (card)
facile à écrire, lisible
le défaut est une carte de test, donc valide
invariant
* valid: is_valid (card)


dès qu’une valeur par défaut raisonnable existe
attention aux “faux nulls”
par exemple, dans la BD, la colonne est nulle
coût
légère surconsommation mémoire

Pattern de la roue libre 3

feature -- Access
* message: STRING
* * attribute
* * * create Result.make_empty
* * end
initialise à une valeur par défaut

Attribut
si on l’initialise directement
message := "Hello world!"
le code de l’attribut ne sera pas exécuté
lazy initialisation automatique…
derrière le compilateur doit insérer des tests
donc c’est parfois plus coûteux que la fourmi

feature -- Access
* message: STRING assign set_message
* * attribute
* * * create Result.make_empty
* * end
feature -- Element change
* set_message (a_message: STRING)
* * do
* * * message := a_message
* * ensure
* * * message_set: message = a_message
* * end

similaire à la fourmi
meilleur quand le coût de création est plus élevé
par exemple, une requête BD…
attention aux “faux nulls”
par exemple, dans la BD, la colonne est nulle

Pattern Iznogoud 4

pourquoi avoir une référence à Void
bogue : erreur d’initialisation ☞ Void-safe

lazy initialisation ☞ zéro pointé, fourmi, roue libre

valeur inconnue : Void a une sémantique métier
la plupart des routines ne font pas de diﬀérence
valeur par défaut et valeur inconnue

Vive la logique booléenne

owner
is_nogood: False

owner
is_nogood: False

owner
is_nogood: True

Inversons la charge
soit la valeur est utilisable, soit elle est inconnue
or la plupart des routines appliquent un défaut
if owner = Void then
* print ("Unknown")
else
* print (owner.name)
end
mais on doit répéter le test partout

la plupart des routines se contentent du défaut

name: STRING attribute Result := "Unknown" end

print (owner.name)

quelques routines traitent diﬀéremment le cas inconnu

if (owner.is_nogood) then
* database.store_name_as_null
else
* database.store_name (owner.name)
end

deferred class IZNOGOUD
* feature {NONE} -- Constructor
* * make_iznogoud
* * * do
* * * * is_nogood := True
* * * ensure
* * * * iznogoud: is_nogood
* * * end
* feature {ANY} -- Access
* * -- default initialization is False
* * is_nogood: BOOLEAN
end

extension des patterns précédents
mais quelques routines ont un traitement spécial
erreur, avertissement, BD, etc.
peu d’algorithmes n’acceptent pas la valeur par défaut
mais il y en a dans la classe

Pattern de l’héritier maudit 5

owner
ACCOUNT: 123 REAL_PERSON: Jack
owner
ACCOUNT: 345 REAL_PERSON: John
owner
ACCOUNT: 567 UNKNOWN_PERSON

<<deferred>>
PERSON

REAL_PERSON UNKNOWN_PERSON

relation Ø-1
pour l’objet lié
des valeurs/traitements par défaut existent
variante plus intelligente du “Null object pattern”
inconvénient : deux classes supplémentaires
avantage : isole les créations par défaut

Pattern singleton orphelin 6

owner
ACCOUNT: 123 STRING: John
owner
ACCOUNT: 345 STRING: John
owner
ACCOUNT: 567 STRING: Unknown
owner
ACCOUNT: 789
{NONE}
unknown_person
SHARED_UNKNOWN_PERSON
shared_unknown: STRING
is_unknown(person: STRING): BOOLEAN

relation Ø-1
pour l’objet lié
des valeurs par défaut raisonnables existent
ou des traitements par défaut
diﬃcile de modiﬁer le graphe d’héritage
librairie ou lisibilité

Pattern de l’objet relation 7


OWNING


OWNING

ACCOUNT: 567


relation Ø-1
on souhaite enrichir la relation
il n’y a pas de valeurs par défaut raisonnables
inconvénient
la navigation entre les 2 objets est indirecte

Pattern detachable 8

quand on ne peut pas travailler avec une valeur
inconnu ou inapplicable
de façon répétitive et très nombreuse
alors Eiﬀel oﬀre une primitive :Void
le compilateur va garantir qu’on n’oublie pas un test

if touch.is_nogood then
* touch.do_special
else
* touch.do_regular
end

if touch /= Void then
* touch.do_special
else
* touch.do_regular
end

chou vert et vert chou, quand c’est fréquent


selon la fréquence de ces tests
si > 85% des algorithmes
avantage
le compilateur garantit qu’on oublie pas un test

Table des matières
APPLICATION
la racine du système
IDEA
un concept dans une arborescence/Mind Map
nom, description
tableau d’enfants

Tout est détachable !
malheureusement
développeur n’a pas perçu le bénéﬁce du Void-safe
donc le code est diﬃcile à lire, peu maintenable
votre mission
supprimer les detachables, test /= Void, etc.
en utilisant les 8 premiers patterns

APPLICATION
note * * * toolbox.description := "9 patterns"
* description : "Void-safe exercice, as a TOC" * * * create exercice
* date : "$Date$" * * * exercice.name := "Exercice"
* revision : "$Revision$" * * * create project_conversion
* * * project_conversion.name := "Conversions"
class * * * toc.add_child (void_safe)
* APPLICATION * * * toc.add_child (language)
* * * toc.add_child (practical_information)
create * * * void_safe.add_child (eiffel_void_safe)
* make * * * void_safe.add_child (micro_exercice)
* * * practical_information.add_child (new_projects)
feature {NONE} -- Initialization * * * practical_information.add_child (project_conversion)
* make * * * new_projects.add_child (options)
* * local * * * new_projects.add_child (void_clarity)
* * * toc, void_safe, eiffel_void_safe, * * * new_projects.add_child (toolbox)*
* * * micro_exercice, language, * * * new_projects.add_child (exercice)
* * * practical_information, new_projects, options, * * * toc.print_as_tree
* * * void_clarity, toolbox, exercice, * * end
* * * project_conversion : detachable IDEA end
* * do
* * * create toc
* * * toc.name := "Formation Void-safe"
* * * create void_safe
* * * void_safe.name := "Void-safe"
* * * void_safe.description := "Eviter une erreur"
* * * create eiffel_void_safe
* * * eiffel_void_safe.name := "Eiffel"
* * * create micro_exercice
* * * micro_exercice.name := "Micro-exercice"
* * * micro_exercice.description := "A corriger"
* * * create language
* * * language.name := "Langage"
* * * language.description := "Nouveautés"
* * * create practical_information
* * * practical_information.name := "Pratique"
* * * create new_projects
* * * new_projects.name := "Les nouveaux projets"
* * * create options
* * * options.name := "Options"
* * * options.description := "Option pour le projet"
* * * create void_clarity
* * * void_clarity.name := "Void-clarity"
* * * create toolbox
* * * toolbox.name := "Boîte à outils"

IDEA
note * * the_children.count + 1)
* description: "One idea/word in a Mind Map." * * * end
* date: "$Date$" * * ensure
* revision: "$Revision$" * * * children_not_void: attached children
* * * child_added: attached children as
class * * * * the_children implies
* IDEA * * * * the_children.has (an_idea)
feature -- Access * * end
* name: detachable STRING assign set_name feature {IDEA} -- Implementation
* description: detachable STRING * print_as_tree_helper (spaces: INTEGER)
* * * * assign set_description * * requireaspaces_positive: spaces >= 0
* children: detachable ARRAY [IDEA] * * do
* * * print_spaces (spaces)
feature -- Display * * * if attached name as a_name then
* print_as_tree * * * * print (a_name)
* * do * * * else
* * * print_as_tree_helper (0) * * * * print ("##unknown##")
* * end * * * end
feature -- Element change * * * print_spaces (spaces)
* set_name (a_name: detachable STRING) * * * print ("%N")
* * require * * * if attached description as a_description then
* * * name_not_void: a_name /= Void * * * * print_spaces (spaces)
* * do * * * * print (">>")
* * * name := a_name * * * * print (a_description)
* * ensure * * * * print ("%N")
* * * name_set: name = a_name * * * end
* * end * * * if attached children as the_children then
* set_description (a_description: detachable STRING) * * * * across the_children as cursor
* * do * * * * loop
* * * description := a_description * * * * * cursor.item.print_as_tree_helper (spaces +
* * ensure 3)
* * * description_set: description = a_description * * * * end
* * end * * * end

* add_child (an_idea: detachable IDEA) * * end
* * require
* * * idea_not_void: an_idea /= Void * print_spaces (spaces: INTEGER)
* * do * * require
* * * if not attached children then * * * spaces_positive: spaces >= 0
* * * * create children.make_empty * * do
* * * end * * * across 1 |..| spaces as i loop print (' ') end
* * * if attached children as the_children then * * end
* * * * the_children.force (an_idea, end
* * * * * * *

Pré-conditions

parameter_not_void: parameter /= Void
devenues inutiles pour les paramètres attachés
laissez-les, au moins dans un premier temps
elles faciliteront d’autres aspects de la conversion
elles permettent de compiler en void-safe ou non

if … /= Void

le plus gros eﬀort
indiquent que Void a un signiﬁcation
ils sont toujours vrais…
donc on doit adapter un test
à analyser au cas par cas

Ajuster les tests
en utilisant nos patterns
ré-écrire le test
if stuﬀ.is_nogood then
utiliser une valeur par défaut ou un tableau vide
ou le rendre detachable
préconditions /= Void, pas de problème

Compromis de contrat
préserver autant que possible le contrat
mais le défaut à changer entre attaché/détachable
à évaluer au cas par cas
pour l’appelant, il est plus facile que vous
retourniez des attachés
acceptiez des détachables, si Void était permis

Void-safe en Eiffel

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Void-safe en Eiffel

Ähnlich wie Void-safe en Eiffel (20)

Void-safe en Eiffel