Les Keyboard Modes ont chacun (cf. le post précédent), une liste des modes atomiques qui les composent : c’est un ensemble au sens mathématique du terme et les caractéristiques et opérations traditionnelles sur les ensembles sont utiles dans notre cas :
- L’ensemble vide : Θ est notre mode vide (EmptyMode).
- L’union : « Ctrl + Shift » U « Ctrl + Frigo » = « Ctrl + Shift + Frigo »
- L’intersection : « Ctrl + Shift » ∩ « Ctrl + Frigo » = « Ctrl »
- La soustraction : « Ctrl + Shift » - « Ctrl + Frigo » = « Shift »
Les prédicats suivants sont pratiques :
- ContainsOne (teste que l’intersection de deux modes est non vide) : X.ContainsOne( Y ) <=> X ∩ Y != Θ
- ContainsAll (teste qu’un mode est totalement contenu dans un autre) : X.ContainsAll( Y ) <=> X ∩ Y = Y
La liste des modes atomiques est ordonnée (selon la comparaison de chaîne ordinale évoquée précédemment) et cette propriété permet d’implémenter les différentes opérations efficacement. L’idée est d’avancer deux index dans les 2 listes (Gauche contient m éléments et Droite en contient n) à traiter en comparant les éléments : à chaque comparaison, on détecte un élément à gauche uniquement, à droite uniquement ou dans les deux.
Lorsque les deux éléments sont égaux, on peut avancer les deux index simultanément, sinon seul l’un des index avance : au pire des cas il y a donc m+n comparaisons et dans le meilleur des cas min(m,n).
L’implémentation repose sur une unique fonction qui applique l’algorithme ci-dessus sur les deux listes et qui est paramétrée par 3 prédicats (des fonctions booléenes prenant un élément en paramètre) :
static void Process( KeyboardMode left,
IKeyboardMode right,
Predicate<IKeyboardMode> onLeft,
Predicate<IKeyboardMode> onRight,
Predicate<IKeyboardMode> onBoth );
Ces prédicats sont appelés dans l’ordre d’apparition des modes atomiques dans les deux modes left et right selon que l’élément apparait à gauche uniquement, à droite uniquement ou dans les deux. Ces fonctions peuvent retourner false pour arrêter le processus. Process est utilisé pour toutes les opérations sur les modes.
Une seule fonction : pour combien d'opérations différentes ?
Voyons d'abord l'implémentation des deux prédicats.
Les prédicats ContainsOne/ContainsAll
ContainsOne est peut-être la plus simple : dès qu’un élément commun est trouvé, on peut conclure positivement et arrêter le processus. Il suffit donc de fournir une fonction qui arrête le processus et mémorise le succès dans le cas où un élément a été trouvé dans les deux listes.
bool IKeyboardMode.ContainsOne( IKeyboardMode mode )
{
bool found = false;
Process( this, mode,
null,
null,
delegate( IKeyboardMode m ) { found = true; return false; } );
return found;
}
ContainsAll est presque identique : c’est le cas « à droite seulement » qui est pisté et l’opposé qui est retourné car si on trouve un mode à droite seulement, c'est que c'est un "alien" qui ne devrait pas être là. (C'est une façon de parler, hein! Les étrangers ont bien le droit d'être là, sinon où serions nous ?)
bool IKeyboardMode.ContainsAll( IKeyboardMode mode )
{
bool foundAlien = false;
Process( this, mode,
null, // Use lambda syntax below instead of delegate keyword.
m => { foundAlien = true; return false; },
null );
return !foundAlien;
}
Un Process, deux prédicats. Il est temps d'aborder les opérations plus complexes.
L’intersection
L’intersection est la plus simple des combinaisons : seuls les éléments qui apparaissent dans les deux listes doivent apparaitre dans le résultat final. On utilise donc une fonction (paramètre onBoth) qui ajoute l’élément à une liste (un collecteur) et continue le processus.
Problème : il nous faut donc appeler la méthode List.Add (qui ne retourne rien) alors que la méthode Process attend un prédicat (une fonction qui retourne un booléen).
Le code est le suivant :
IKeyboardMode IKeyboardMode.Intersect( IKeyboardMode mode )
{
List m = new List<IKeyboardMode>();
Process( this, mode, null, null, Adapter.AlwaysTrue<IKeyboardMode>( m.Add ) );
return Context.ObtainMode( m );
}
L’adaptateur qui suit permet d’envelopper (wrapper) une action dans un prédicat toujours vrai :
public class Adapter
{
static public Predicate<T> AlwaysTrue<T>( Action<T> a )
{
return delegate( T o ) { a( o ); return true; };
}
}
L’air de rien, ces quelques lignes mettent en œuvre simultanément les génériques, les fonctions anonymes et la clôture.
Personnellement je trouve ça superbe et c’est - à mon humble avis - un exemple de code qui démontre bien la puissance de ce drôle de langage que devient C#.
J’ai cependant essayé de trouvé plus élégant, l’appel devenant par exemple :
// Perfection (at least for me)… Sadly, it does not work.
var actionAlwaysTrue = m.Add.ToPredicate( true );
Malheureusement, cette solution (une méthode d’extension sur le delegate Action) ne permet que d’écrire :
var actionAlwaysTrue = ((Action<IKeyboardMode>)m.Add).ToPredicate( true );
Car la méthode Add doit être explicitement considérée comme un delegate afin que les méthodes d’extension puissent s’appliquer. De même, la forme suivante n’est pas syntaxiquement correcte :
// Not perfect… And does not work.
var actionAlwaysTrue = Adapter.ToPredicate( m.Add, true );
Le compilateur exige la définition explicite du type, celui-ci ne pouvant être inférée par le type de l’action, ce qui nous ramène à :
var actionAlwaysTrue = Adapter.ToPredicate<IKeyboardMode>( m.Add, true );
Alors, en désespoir de cause, je préfère conserver mes deux petits helpers AlwaysTrue (et AlwaysFalse) :
var actionAlwaysTrue = Adapter.AlwaysTrue<IKeyboardMode>( m.Add );
L’union, la soustraction et le toggle
L’union se définit ainsi : que l’élément apparaisse à droite, à gauche ou dans les deux, il doit apparaitre dans le résultat final. C’est donc la même fonction qui est fournie aux 3 cas et qui ajoute l’élément à la liste (le collecteur).
IKeyboardMode IKeyboardMode.Add( IKeyboardMode mode )
{
List<IKeyboardMode> m = new List<IKeyboardMode>();
var add = Adapter.AlwaysTrue<IKeyboardMode>( m.Add );
Process( this, mode, add, add, add );
return Context.ObtainMode( m );
}
Ici, j’ai utilisé var pour définir la variable car le contexte est suffisamment explicite et l’algorithme suffisamment simple. En règle générale, je type explicitement mes variables : d’expérience le code est nettement plus lisible et maintenable ainsi.
La soustraction consiste à ne conserver que les modes qui apparaissent à gauche :
IKeyboardMode IKeyboardMode.Remove( IKeyboardMode mode )
{
List<IKeyboardMode> m = new List<IKeyboardMode>();
Process( this, mode, Adapter.AlwaysTrue<IKeyboardMode>( m.Add ), null, null );
return Context.ObtainMode( m );
}
Le petit dernier est le « Toggle ». Intuitivement, il s’agit de l’opération qui « inverse » l’état d’un mode particulier, par exemple :
- Toggle( « Ctrl + Shift », « Ctrl » ) => « Shift »
- Toggle( « Shift », « Ctrl » ) => « Ctrl + Shift »
En quelques mots: si le mode est présent je le retire, sinon je l’ajoute. Evidemment, cela doit fonctionner avec plusieurs modes :
- Toggle( « Ctrl + Shift », « Ctrl + Frigo » ) => « Shift + Frigo »
- Toggle( « Shift + Frigo », « Ctrl + Frigo » ) => « Ctrl + Shift »
Ce toggle est trivial à implémenter grâce à la fonction Process car il suffit simplement de collecter ceux qui sont à gauche, ceux qui sont à droite, mais pas les éléments communs.
IKeyboardMode IKeyboardMode.Toggle( IKeyboardMode mode )
{
List<IKeyboardMode> m = new List<IKeyboardMode>();
var add = Adapter.AlwaysTrue( m.Add );
Process( this, mode, add, add, null );
return Context.ObtainMode( m );
}
This is the end. Mais j’ai pourtant eu envie de continuer…
Toutes les opérations possibles ?
Intrigante cette fonction Process qui permet de tout implémenter. A-t-on oublié des opérations intéressantes ?
Mon idée est de me servir de Process pour vérifier que je n’ai rien oublié : le tableau suivant recense toutes les utilisations possibles de la méthode d’ajout à un collecteur (il y a 3 slots, chacun pouvant être null ou add, il y a donc 23 = 8 possibilités).
| onLeft |
onRight |
onBoth |
Name & description |
Comments |
| null |
null |
null |
“Empty” |
Useless. |
| null |
null |
add |
Intersect (keep commons) |
Implemented. Kind of symmetric of ‘Toggle’. |
| null |
add |
null |
“Cleanup” (keep theirs only) |
Useless since it is the symmetric of ‘Remove’ |
| null |
add |
add |
“Other” (keep theirs and commons, reject mine) |
Useless. Opposite of ‘This’. |
| add |
null |
null |
Remove (keep mine only) |
Implemented. Opposite of ‘Cleanup’ |
| add |
null |
add |
“This” (keep mine and commons and reject theirs) |
Useless. Opposite of ‘Other’. |
| add |
add |
null |
Toggle (keep mine, theirs, but reject commons) |
Implemented. |
| add |
add |
add |
Add |
Implemented. |
Ces 4 fonctions couvrent bien l’ensemble des opérations sensées. Vous certainement pas, mais moi, ce constat me rassure 
.
PS: Pourquoi le tableau ci-dessus est-il en anglais ? Parceque qand je code, je "suis" en anglais. Et que ce tableau, je l'ai fais dans le code.
