Blogue

Propriétés et fonctions

Nous avons actuellement deux problèmes reliés aux propriétés à résoudre pour la version 2 du langage de programmation D. Un premier viens du fait que les fonctions sans argument peuvent être appelées autant avec ou sans les parenthèses vide, ce qui crée des ambiguities lorsqu’une telle fonction retourne un type appelable (un pointeur de fonction, un delegate ou un objet avec un membre opCall). Le deuxième problème est que l’on veut que les proprieties soit des noms ou adjectifs et les actions des verbes. En anglais, beaucoup de mots sont à la fois nom, adjectif et verbe ce qui rend difficile de distinguer les fonctions par leur nom seulement.

Résoudre le premier problème revient à pouvoir déterminer quelles fonctions peuvent et doivent être appelées sans parenthèses. À moins de vouloir forcer toutes les fonctions sans paramètre à être appelé sans « () », nous devons avoir un indicateur discriminant les fonctions qui nécessite et celle qui ne nécessite pas de « () ».

Le deuxième problème est plus complexe. Il s’agit de la signification des mots. Prenons par exemple une fonction transform. En lisant ce nom de fonction, vous développerez une idée de ce qu’elle fait. Alors je vous demande : est-ce qu’une fonction transform est une action (un verbe) dans le sens qu’elle applique une transformation à un objet, où est-ce une propriété (un nom ou un adjectif) dans les sens qu’elle retourne quelque chose tel une « affine transform » associée à un objet ? La sémantique des deux est complètement différente, pourtant les deux partagent le même nom.

La véritable ambiguïté ici vient de la langue anglaise où plusieurs noms et adjectifs sont aussi des verbes. On pourrait passer à une langue qui n’a pas ces problèmes — par exemple le français : « transform » devient transformer (action, verbe) ou transformation (propriété, nom) ; « empty » devient vider (action, verbe) ou vide (propriété, adjectif) — mais ça ne semble pas une option viable.

Alors à part de passer à autre chose que l’anglais, nous avons deux autres options. Premièrement, nous pourrions écrire des règles dans un guide de programmation demandant à ce que les propriétés (noms, adjectifs) débute par un préfixe particulier. Je l’ai essayé, et je n’ai pas réussi à trouver quelque chose de raisonnable qui fonctionne pour les propriétés non-booléenes. C’est sans compter que la plupart des gens ne lisent pas ce genre de règle ; éduquer les utilisateurs pour qu’ils préfixent leur propriétés booléennes de « is », « has » ou d’un verbe modal serait un effort majeur. Ça fonctionne en Objective-C, mais la syntaxe des fonctions est complètement différentes en Objective-C.

La seule option restante, en assumant qu’on veuille toujours régler le problème, est d’introduire une syntaxe plus formelle en D pour distinguer les propriétés (noms, adjectifs) des actions (verbes). Un candidat tout naturel est d’utiliser la syntaxe sans parenthèse pour les propriétés, imitant ainsi les variables, et d’utiliser la syntaxe de fonction héritée des langages dérivés du C pour les actions. Trouver une bonne syntaxe pour définir une propriété est un défi plus compliqué puisqu’elle doit aider les programmeurs à faire le bon choix à savoir s’ils veulent une propriété ou une action sans non plus trop dévier de la syntaxe d’une fonction.

Et pour ce qui est de savoir si une propriété doit avoir un faible coût (ne rien faire de lourd), c’est un autre débat qui pourrait définir une norme de programmation.


Ceci est une adaptation d’un message posté sur le newsgroup du langage D.


Trop d'icônes c'est comme pas assez

Microsoft a parti le bal il y a longtemps déjà en créant un icône pour chaque action possible de sa suite Office de façon à pouvoir en mettre le plus possible ses barres d’outils surpeuplées. Puis, sur Windows, ils ont décidé de faire des menu avec un style spécial pour placer les icônes aux cotés de chaque commande. Sur Linux, KDE et Gnome ont fait la même chose mais d’une façon plus cohérente en le faisant pour toutes les applications, puis ils en ont ajouté dans les boutons des boîtes de dialogue. Maintenant, Gnome va s’en débarrasser. Bon débarras !

J’ai toujours trouvé distrayant les icônes dans les boutons et les menus. Placer un icône à coté du texte du bouton ou du menu est inutile à mes yeux : je peux lire aussi vite sinon plus vite que je peut déchiffrer un icône, et le texte est plus descriptif et plus utile. Avoir un icône à côté du texte ajoute du bruit inutile au bouton ou à l’élément d’un menu.

Ceci dit, un icône n’est pas inutile s’il ajoute une information supplémentaire : l’icône d’un fichier ou d’un dossier à côté de son nom est parfaitement justifié puisqu’il permet d’avoir une meilleure idée de ce dont il s’agit. L’icône d’une case à cocher de même.

Je ne m’oppose pas non plus aux boutons n’ayant qu’un icône, sans texte. Ils sauvent de l’espace lorsque c’est nécessaire et ils sont généralement assignés à des tâches suffisamment différentes pour qu’on puisse leur donner un icône bien distinctif. Les flèches de la barre d’outil de votre navigateur en sont un bon exemple.

Avoir à trouver un icône pour chaque bouton et commande de menu rend plus difficile de créer des applications de qualité. Avec Gnome, si un bouton n’a pas d’icône il n’aura pas l’air à sa place. D’un autre côté, créer ou trouver un icône représentatif pour chaque bouton d’une application peut s’avérer une tâche difficile. Cette difficulté fait que souvent les icônes sont peu représentatif, ou que le même icône est utilisé pour différente tâches. Par exemple, quel est la différence entre un icône pour « enregistrer » et « enregistrer sous » ?

Quelqu’un dans les commentaires d’un article de OSNews sur le sujet nous indique que ces icônes sont optionnels dans KDE, et nous montre la différence entre avec ou sans icône. Quelle copie d’écran préférez-vous ?


Adapté à MobileSafari

Je voulais depuis quelque temps rendre mon site web plus attrayant sur un iPhone ou un iPod Touch. J’ai essayé quelque chose il y a un peu plus d’un an en ajoutant des « media queries » à ma feuille de style pour que les règles déjà applicables à @media handheld s’applique aussi au iPhone. Une fois testé cependant, le résultat n’était pas vraiment génial. Par contre, maintenant que j’ai un vrai iPod Touch, j’ai pu expérimenté un peu plus.

Le but est ne ne pas avoir à zoomer pour lire le contenu, le défilement vertical devrait être l’unique chose nécessaire. Les contraintes techniques que je me suis imposés sont :

  1. Pas de page séparé pour MobileSafari. Bien que ça aurait été certainement possible, mes pages sont déjà assez légères pour rendre cette idée plutôt inutile.

  2. Tout ceci ne concerne que la présentation du site, il ne devrait donc pas y avoir rien à modifier dans le HTML des pages. Tout devrait être fait à partir des feuilles de style.

Cette deuxième contrainte était un peu problématique vu qu’Apple a décidé pour certaines raisons qui m’échappent que le « viewport » pour la page serait placé dans un tag meta dans l’entête du fichier HTML, comme ceci :

<meta name="viewport" content="width=808" />

Ceci me laisse sans la possibilité de changer la largeur du contenu en pixel virtuel, et MobileSafari n’est pas assez brillant pour se rendre compte que mon site n’utilise pas tous les 980 pixels virtuels pour changer la largeur de façon adéquate.

J’ai finalement solutionné le problème en utilisant la directive CSS -webkit-text-size-adjust (spécifique à MobileSafari) pour augmenter la taille du texte jusqu’à ce que la page couvre toute la largeur de l’écran. Le désavantage de cette approche est que les images restent un peu trop petites, mais puisque ce site contient principalement du texte, et puisqu’il est facile de zoomer sur les images avec un iPhone, ça ne fait pas grand mal.

Maintenant, il y a beaucoup plus que ça dans ma feuille de style handheld/MobileSafari, notamment l’usage de Helvetica au lieu de Palatino et un petit rearrangement de ma page d’accueil pour éviter d’avoir deux colones. Et j’aime bien le résultat, puisqu’il n’est pratiquement plus nécessaire de zoomer sur quoi que ce soit maintenant.

Et je viens juste de réaliser qu’avec le iPhone SDK disponible gratuitement de Apple, il n’est pas nécessaire d’avoir un véritable appareil entre les mains pour tester son site web avec MobileSafari. Le SDK contient un simulateur de iPhone qui inclus MobileSafari, qui est parfaitement adéquat pour tester. La seule chose qui va vous manquer c’est la grande résolution de l’écran du iPhone/iPod Touch… et peut-être la difficulté de toucher les bons éléments avec vos doigts.


Problèmes avec Multi-Safari et les mesures anti-pourriel

Comme plusieurs me l’on fait remarqué, les téléchargements de Multi-Safari ne fonctionnaient plus ces deux derniers jours. C’est maintenant réparé. Pour ceux qui m’ont envoyé un message par courriel et qui n’ont pas reçu de réponse, désolé. Je n’ai pas pu répondre à tout le monde, mais aussi plusieurs de mes tentatives de réponse ont été bloqués par des filtres à spam un peu trop scrupuleux qui ont placé le serveur d’envoi de courrier de mon fournisseur sur leur liste noire temporaire. Ça aussi devrait se réparer, enfin j’espère.

Alors pour tout ceux qui comptaient sur Multi-Safari, et tout ceux qui m’ont écrit sans avoir de réponse : désolé pour les inconvénient.



  • © 2003–2024 Michel Fortin.