Jump to: navigation, search

Les choix problématiques de Ben et Casey

Introduction

S'il est besoin de le rappeler, processing.org est développé en Java. Pour résumer rapidement, Java est un language de programmation orienté objet, complet (dans le sens où il peut accomplir la majorité des tâches possibles via un ordinateur) et multi-plateforme. Ce dernier aspect est sa grande force. D'autres langages, tel le C ou e C++, nécessitent une compilation spécifique à chaque OS . Le coût de cette inter-opérabilité est la nécessité d'installer une machine virtuelle, le JRE, pour pouvoir faire tourner les applications.


Processing-ide.png


Le projet de Casey Reas et de Benjamin Fry étant de rendre l'accès à la programmation le plus simple possible, ils ont été amenés à automatiser les aspects les moins sexy du Java, et plus largement de la programmation. Une quantité importante de concepts est en effet masquée par cet IDE sommaire.

Un newbee se lançant seul avec processing risque fort de passer à côté de Java et de prendre des habitudes relevant du scripting Javascript ou Python. Ces 2 langages sont, à mon sens, beaucoup plus propices à l'apprentissage de la programmation que processing.

L'absence de la classe principale

La déclaration de la classe principale, le point d'entrée du programme, est absente de l'éditeur. Dans la capture d'écran ci-dessus, il est en effet très facile d'oublier que le texte class Particles extends PApplet est nécessaire à la compilation du programme.

De vraies/fausses classes

Toujours en me basant sur l'exemple ci-dessus, les 2 onglets Particle et ParticleSystem sous-entendent qu'il s'agit de deux classes séparées de la classe principale. Quand vous accéder au contenu du dossier, vous constatez en effet que 3 fichiers sont présents: Particles.pde, Particle.pde et ParticleSystem.pde. Il faut rappeler que, en Java, chaque fichier représente une classe, et doit porter le même nom que la classe qu'il contient. Hors, le nom de ces onglets n'est en rien lié à la classe qu'ils contiennent et il est tout-à-fait possible de placer dans un onglet une méthode de la classe principale. Cette flexibilité dans l'organisation du code source est favorable, pour des non-programmeurs, à un certain désordre.

Deuxièmement, les fichiers .pde générés par l'IDE sont des fichiers au format .txt. Il ne sont en rien des fichiers .java. Quand le bouton run est pressé, l'IDE copie le contenu de ces fichiers dans un seul fichiers .java en y ajoutant ce qui est nécessaire, le compile et lance l'application.

Les classes présentent dans ces onglets sont en réalité de Nested class (ou inner class) (trad: classes imbriquées). Ce système puissant d'imbrication a néanmoins des effets secondaires invisibles à l'utilisateur même averti de processing, notamment au niveau de la portabilité du code.

Variables globales à gogo

Dans les variables les plus utilisées par les sketches processing, on retrouve width et height. Ces deux valeurs sont utilisables partout dans le code. Tant qu'elles sont accédées dans le contexte de l'objet principal, c'est tout-à-fait naturel. Par contre, quand une de ces variables est utilisées dans le contexte d'un sous-objet, Particle par exemple, la non-connaissance de cette imbrication laisse supposer que width et height sont des variables remontant de l'OS, passée à l'application par l'OS, et non extraites par l'application elle-même. Cette différence qui peut paraître subtile est fondamentale quand il s'agit de prendre le contrôle sur la fenêtre dans laquelle le sketch est présenté.

Un des effets secondaires des nested classes est de casser la sécurité induite par les mot-clés private et protected. Aucune erreur de compilation n’apparaît quand par exemple la classe Particles accède directement à une variable privée d'une Particle.

New ou load?

Pour assurer une simplification maximisée, processing met à disposition des méthodes de chargement d'objet automatisées et efficaces. Dans ces méthodes, l'instanciation de l'objet se passe dans la méthode, qui retourne ensuite un objet prêt à l'usage. C'est le cas des méthodes loadGraphics et loadImage notamment.

Focus sur les premières lignes de la méthode setup de l'exemple:

 sprite = loadImage("sprite.png");
 ps = new ParticleSystem(10000);

La facilité de création du sprite cache l'opération de création de cet objet, opération visible dans la ligne suivante par la présence du mot-clé new. Ces 2 lignes ne suivent pas la même logique, dans la première quelque chose fait le travail à la place du programmeur, dans la deuxième l'instanciation est manuelle. Pour un débutant, qui par définition n'a pas de baguage de programmation, ces 2 manières de faire la même chose sont une source de confusion importante.

Plafond de verre

Le soucis de simplification a amené les créateurs de processing à produire une documentation à l'image de leur IDE.

L'exemple PImage.

L'objet PImage, un des plus utilisés dans les projets processing, permet de charger des images et de les afficher. La documentation de l'objet, disponible en ligne et en local, reprend très sommairement les méthodes qu'il contient. Aucune infromation n'est disponible quant aux objets desquels il hérite, des interfaces qu'il implémente et des variables statiques qu'il utilise. Bizarrement, une note indique de ne pas utiliser new PImage() ( Do not use the syntax new PImage() ), sans autre explication. Pourtant, le constructeur est définit dans le bas de la page. Aucun lien ne permet d'en savoir plus...

Pour une information complète sur cet objet, il faut passer par un moteur de recherche (la recherche sur le site utilisant google) et connaître le mot-clé Javadoc. Cette documentation existe bel et bien et est disponible à cette adresse. Le détail de la classe PImage se trouve ici: PImage.html.

Le manque de fluidité entre la version light et la version complète de la documentation est un des facteurs entretenant le plafond de verre expérimenté par la plupart des autodidactes.

L'accés aux couches internes du frameworks est indispensabe quand la complexité du code augmente ou que des opérations avancées doivent être accomplies. Le fondement de l'orienté objet est en effet de repartir d'une classe existante et d'y ajouter les variables et méthodes nécessaires, sans la réécrire complètement. Le package processing.core étant pré-compilé dans core.jar, donc inaccessible au moteur de recherche interne de l'OS, la javadoc étant difficilement accessible sans connaître le terme, un débutant aventureux se retrouve rapidement bloqué dans son apprentissage.

Resources


--Frankiezafe (talk) 16:01, 7 October 2015 (CEST)