Inférence de type en Eiffel

L’inférence de type est un mécanisme permettant au compilateur de déduire automatiquement le type d’une cible en se basant sur le type de la source.
L’utilisateur n’a alors plus besoin de déclarer ses variables et donc de se soucier du nom du type qui rentre en jeu. Le programme obtenu est plus générique, plus à même aux changements. En effet si le type de la source change, le type de la cible est automatiquement modifié.
L’inférence de type apporte une plus grande souplesse au typage statique.

Typage statique

Exceptés deux cas (nous en verrons un par la suite), une variable ou un attribut en Eiffel doit toujours être déclaré.
Ci-dessous est définie une classe LINE avec une procédure de création (constructeur) from_complexs et deux attributs first et second de type POINT.
La procédure de création prend deux paramètres de type COMPLEX et crée les deux attributs.


class
	LINE

create
	from_complexs

feature -- Initialization

	from_complexs (a, b: COMPLEX)
		do
			create first.from_complex (a)
			create second.from_complex (b)
		end

feature -- Access
	
	origin: POINT
		once
			create Result
		end

	first, second: POINT

end

Typage ancré

Le typage ancré a été introduit dans Eiffel pour apporter une plus grande flexibilité au typage statique et pour permettre la covariance dont nous ne parlerons pas dans cet article.
Il permet de spécifier que le type d’une cible est identique au type d’une source.


origin: POINT
	once
		create Result
	end

first, second: like origin

Les attributs first et second sont du même type que la fonction (à exécution unique) origin.

Le typage ancré permet d’écrire un programme plus générique et évolutif. Cependant, la déclaration des variables est toujours nécessaire.

Eiffel void safe

Nous souhaiterions donner à l’utilisateur la possibilité de spécifier un paramètre comme vide (nul).
Une variable, ou un attribut pouvant être affecté de la valeur vide doit être déclaré comme « detachable ».
La variable étant potentiellement vide, il est nécessaire de faire un test d’attachement avant de lui appliquer des opérations.


from_complexs (a: COMPLEX; b: detachable COMPLEX)
	do
		create first.from_complex (a)
		if b /= Void then
		      create second.from_complex (b)
		else
		      create second.from_complex (origin)
		end
	end

b /= Void peut être remplacé par attached b.
b est en lecture seule à l’intérieur de la condition.

En revanche aucune opération n’est applicable sur un attribut détachable, car sa valeur peut être modifiée lors de l’appel d’autres procédures. Il est donc nécessaire d’avoir un mécanisme qui fasse à la fois un test d’attachement et une affectation à une variable locale. Le patron d’attachement est ce mécanisme. Il peut bien entendu être utilisé avec des variables locales comme illustrées ci-dessous.


from_complexs (a: COMPLEX; b: detachable COMPLEX)
	do
		create first.from_complex (a)
		if attached b as c then
		      create second.from_complex (c)
		else
		      create second.from_complex (origin)
		end
	end

Si b est attaché à un objet alors il est affecté à la variable locale c. La variable nouvellement créée est en lecture seule comme le sont les paramètres formels ou les constantes.
Le mécanisme introduit par la même occasion une inférence de type.

Proposition d’une inférence de type

Une première approche pourrait être de déduire le type d’une variable lors de sa première affectation.


new_target := source

Mais cette approche à plusieurs inconvénients :
— Le compilateur ne peut pas détecter les erreurs de frappes. C’est une erreur récurrente et qui n’est pas si facile à identifier sans le compilateur.


new_target := source
mew_target := source2

— Nous pouvons par erreur utiliser le nom d’un attribut de notre classe. Le compilateur n’a aucun moyen d’identifier cette erreur.
— La sémantique d’une affectation devient plus complexe. En effet, elle peut conduire à la création d’une nouvelle variable.

Nous avons besoin d’un mécanisme distinct d’une affectation qui provoque la création d’une nouvelle variable.

En faisant une petite recherche sur les moteurs de recherche, on peut trouver une proposition qui va dans ce sens.


new_target ::= source

Cependant la syntaxe utilisée est nouvelle et se démarque peu d’une affectation.

En nous inspirant du patron d’attachement, nous pouvons créer un mécanisme simple.


source as new_target

Quel est le type de la cible ?
La cible est du type de la source. Lorsque la source est détachable, le mécanisme a peu d’intérêt. Dans ce cas, il est préférable d’utiliser le patron d’attachement. Nous pouvons donc réserver ce mécanisme aux sources de type attaché.

La variable nouvellement créée doit-elle être en lecture seule ?
Le mot clé « as » suggère une liaison plus forte entre la cible et la source qu’avec une affectation.
Les variables en lecture seule garantissent l’accès à un même objet tout au long de la routine, évitant ainsi une erreur d’interprétation.
Je pense qu’il est donc judicieux d’avoir la variable nouvellement créée en lecture seule.

Ce choix peut toujours être révisé dans une version ultérieure. En effet, l’introduction de la mutabilité d’une variable inférée sera rétrocompatible, l’inverse ne l’est pas.
Ce choix est également motivé par la volonté d’avoir un maximum de similitudes sémantiques avec le patron d’attachement.


if attached (source as new_target) then
	new_target.do_something -- compilation error
end

la compatibilité est atteinte en considérant que source as new_target est une expression qui donne comme résultat la variable nouvellement créée.
Nous pouvons remarquer un changement sémantique qui n’a aucune conséquence effective. En effet lorsque la source est détachable, le type de la cible n’est plus attaché, mais détachable.

Cependant, la distinction nette entre expression et déclaration en Eiffel pousse à garder une séparation entre le mécanisme proposé ici et le patron d’attachement.

Résumons :
1. Le type de la source doit être attaché.
2. Le nom de la cible ne doit pas identifier une autre variable.
3. Le type de la cible est identique à celui de la source.
4. La cible est en lecture seule.
5. Le mécanisme provoque la création d’une nouvelle variable et son initialisation.
6. Le mécanisme n’est pas une expression, mais une déclaration.

Motorola RAZR i

A la recherche depuis quelques semaines d’un nouveau smartphone, j’ai finalement été séduit par le Motorola RAZR i.
Comme à l’achat de mon précédent smartphone, je recherchais un appareil avec une particularité qui le distingue des autres.

Mon précédent smartphone, le Motorola Atrix, a l’originalité d’être le seul à posséder un déverrouillage par reconnaissance digitale. Pour ceux qui souhaitent plus de détail, il s’agit d’une reconnaissance digitale résistive. Au premier abord, ça peut paraître gadget, mais c’est terriblement efficace et agréable au quotidien. Je regrette que Motorola n’ait pas reconduit l’expérience sur ses nouveaux modèles. Il fut également le premier à intégrer le processeur Nvidia Tegra 2 (double coeur). Cette intégration n’apporta pas que des avantages. En effet, le système Android 2.3 a une compatibilité limite avec le Nvidia Tegra 2, ce qui provoque quelques ralentissements lors du visionnage de vidéo Full HD. Il existe quelques autres caractéristiques exotiques de l’appareil, notamment le fait qu’il embarque un système d’exploitation Desktop.

Équivalent européen du Motorola RAZR M, le RAZR i a la particularité, comme l’indique le “i” de son nom, d’être le premier smartphone à embarquer un processeur Intel.
Il s’agit du modèle milieu de gamme, quoique légèrement au-dessus, de la famille RAZR. Le modèle haut de gamme correspond au Motorola RAZR HD et Motorola MAXX HD.

Processeur

Le processeur intégré a un coeur cadencé à 2 GHz. La haute fréquence permet d’atteindre un très bon niveau de performance qui se place au-dessus des ARM double coeur et en deçà des ARM quatre coeurs.
La possession d’un seul coeur lui confère une certaine réactivité. J’ai pu observer un temps de démarrage plus court que sur le Motorola Atrix et globalement des performances et une réactivité meilleures.

Mais il existe un revers. Certains jeux exploitent des particularités des processeurs ARM, les rendant incompatibles avec ce processeur. Heureusement ils ne sont pas en grand nombre.
razr i intel

Ergonomie

Motorola reste fidèle à lui-même. De fait le RAZR i a une finition exemplaire pour un smatphone de milieu de gamme.
Il a la particularité d’avoir une séparation très courte entre le bord de l’appareil et l’écran. En effet les bords droit et gauche semblent presque inexistants, réduisant grandement sa largeur.
Il se rattrape un peu sur la longueur. Il offre un bord assez large en dessous de l’écran qui finit par se replier vers l’arrière. Cette largeur permet une meilleure prise en main et l’inclinaison donne du cachet au RAZR i. aucune touche sensitive ne sont présentes. Les touches sont présentes dans l’interface d’Android.
Au-dessus de l’écran, on retrouve le LED de notification en parfaite symétrie avec la caméra frontale. On retrouve également le logo Motorola. À première vue j’ai trouvé que ce logo gâché un peu l’esthétique frontale de l’appareil, mais en réalité ça démarque de manière élégante l’appareil et dissimule par la même occasion le haut-parleur.
Comparé au Motorola RAZR il s’épaissie un peu pour atteindre huit millimètres. Ce qui est déjà très fin.
Sur le côté gauche on retrouve le compartiment permettant d’insérer la micro-SIM et éventuellement une carte micro-SD, ainsi que le port micro-USB.
Le côté droit est muni de trois boutons. Les deux boutons du haut permettent respectivement d’éteindre/allumer et de régler le volume. Le troisième bouton en bas est rétracté, l’effaçant des lignes générales du smartphone. Il permet d’activer la caméra.
La présence de chaque côté de trois vis donne un style industriel, masculin au smartphone.
RAZR i vue lateral
La partie haute du dos de l’appareil est glossy et laisse place à la caméra de huit Mégapixels, son flash ainsi qu’un haut-parleur.
La partie basse est faite de Kevlar qui apporte une très bonne finition. La texture douce est agréable au touché et ne glisse pas dans la main.
Comparé au Motorola RAZR HD, le Kevlar ne s’étend pas jusqu’au bord de l’appareil. La résistance de ces derniers doit donc être limitée comme n’importe quel autre smartphone.
Toutefois, les bords sont légèrement plus incurvés que sur certains autres smartphones, l’iPhone par exemple, lui offrant sans doute une plus haute résistance aux chutes.
RAZR i dos

Périphériques

Écran

L’écran de 4.3 pouces a une résolution qHd. Cette résolution est suffisante, mais c’est dommage de ne pas avoir installé un écran HD quant on sait que le processeur permet la lecture de vidéo Full HD …
L’écran utilise la technologie Super AMOLED Advanced ce qui le rend moins brillant qu’un Super AMOLED.
Il n’apporte pas d’avantages supplémentaires en extérieur que ses concurrents. Le mieux reste encore d’activer le réglage automatique de la luminosité de l’écran.
Vivement les écrans passifs !

Caméra

L’appareil photo de huit Mégapixels peut être lancé en moins d’une seconde avec le bouton dédié. On a l’impression d’un lancement instantané; je n’ai jamais vu quelque chose de comparable. Le processeur doit y être pour quelque chose.
Lors de la prise de la photo, le focus est automatique. Il peut être choisi en le sélectionnant sur l’écran.
À noter qu’une fonction HDR est proposée et un mode rafale plutôt efficace.
L’interface du logiciel dédié à la caméra est personnalisable.
camera

Autres

Le RAZR i est compatible 4G et possède la technologie NFC.
La batterie du RAZR i n’est pas amovible. Cette batterie de 2000 mAh, associée aux Smart Actions (voir ci-dessous), permet de dépasser largement une journée d’autonomie.

Logiciels

Le Motorola RAZR i embarque la version 4.0 d’Android et devrait recevoir les mises à jour vers une version plus récente début printemps. En effet le processeur Intel exige quelques adaptations d’Android ce qui ralentit le déploiement des mises à jour.
Motorola, racheté il y a peu de temps par Google, s’est [enfin] débarrassé de Motoblur. Je n’appréciais guère cette surcouche qui dénaturée un peu Android.
On retrouve un Android presque pur. Motorola a en effet ajouté quelques éléments qui rendent le système plus pratique et plus plaisant au quotidien. Le navigateur par défaut d’Android a été remplacé par Chrome, ce qui est une excellente initiative.
On peut par exemple noter l’ajout d’un écran de configuration rapide à gauche de l’écran d’accueil permettant d’activer ou de désactiver rapidement WiFi, GPS, NFC, Bluetooth.
Mais le plus intéressant est la présence des Smart Actions et de la station de bureau.

Smart Actions

Il est possible de spécifier que lorsque plusieurs conditions sont vérifiées, plusieurs actions sont exécutées, maintenues.
Par exemple il est possible de créer une Smart Action qui active l’application Musique quand des écouteurs sont connectés.
Il est possible de changer le fond d’écran, de baisser la luminosité, d’éteindre la WiFi lorsque la batterie est faible et qu’elle n’est pas en train d’être chargée.
J’ai ainsi pu créer une Smart Action de Veille qui me permet de détériorer d’à peine 4 % ma batterie durant la nuit.

Station de Bureau

Associé à un Dock l’application Station de Bureau transforme l’appareil en radio-réveil. Vous disposez d’un affichage large de l’heure et d’un ajout possible d’autres informations (Météo, agenda, playlists…).

Les qualités d’un système

Il n’est pas facile de concevoir un nouveau système. Une question revient souvent : par où commencer ?

Je pense qu’il faut d’abord se poser deux questions :
Qu’est-ce qu’un système ?

Quelles sont les qualités d’un système ?

Je vais tenter d’introduire une réponse sommaire à ces deux questions :

Un système est un ensemble d’entités et de relations entre ces entités.
Le choix des entités et de leurs relations n’est pas aisé. Pour simplifier cette tâche, il doit être guidé par un certain nombre de critères soigneusement choisis. Ces critères constituent les qualités d’un système.

Stabilité

Il est évident que la première qualité d’un système est d’être stable.

en d’autres termes de fonctionner correctement, de répondre aux exigences de sa spécification et de réagir de façon appropriée à des évènements inattendus, des évènements qui ne font pas partie de sa spécification.

Réutilisabilité

Un système réutilisable est un système utilisé pour concevoir de nouveaux systèmes.

On constate que certains systèmes ont de nombreux points communs. Ces systèmes auraient pu reposer sous un même sous-système.

Afin d’atteindre cette qualité nous devrions essayer de concevoir des systèmes soigneusement décomposés en sous-systèmes et généralisés au maximum.

Performance

Un système performant est un système minimisant son occupation spatiale et temporelle. Il minimise les ressources qu’il utilise et réagit rapidement.

Simplicité

Un système se doit d’être simple pour la facilité de son appréhension.

Beaucoup de systèmes sont conçus pour un public précis. Il s’avère que souvent ces systèmes finissent par être utilisés par un public plus large.

Le système est alors mal adapté et est complexe pour tous ceux qui ne font pas partie du groupe initialement ciblé.

Je pense qu’un système simple doit être généralisé. Il doit s’appuyer sur le moins de suppositions possible. Il doit utiliser un minimum de concepts; des concepts clairs, cohérents, puissants et si possible intuitifs.

Flexibilité

Un système flexible est capable de s’adapter aux circonstances. J’entends par flexible un système configurable et compatible avec d’autres systèmes, d’autres environnements.

Fonctionnalité

Un système fonctionnel offre un grand nombre de possibilités.

Les utilisateurs demandent toujours plus de fonctionnalités. Cet ajout représente souvent l’évolution majeure d’un système. L’addition de fonctionnalités peut complexifier le système et briser sa cohérence.

Des ajouts ultérieurs de fonctionnalité doivent être prévus dès la conception.

Chaque qualité ne peut être considérée séparément. Elles sont étroitement liées et doivent faire l’objet d’un compromis.