====== Java : Evolution du cours ====== =====Planning===== * Semestre 1 : jusque Expressions * CUV : Attention le chapitre OO devra être vu avant le TD6. L'année passée nous avons du voir la grammaire après l'OO. Pourquoi pas faire ce changement dans les notes? * MCD : C'est pour ça que l'OO apparaît au TD6 et plus au TD5 comme l'année passée. Je préfère ne pas changer dans les notes pour tenter de rester en phase avec le cours de logique. * Semestre 2 : Interro formative + suite du cours * MCD: C'est peut-être une bonne idée de mettre l'interro formative en début de second semestre. On peut juger du nouveau groupe et rappeler la matière. * DNA : @MCD ils sortent des examens, pas la meilleure place. =====Leçons===== === Programme et langage de programmation === * Ca serait bien d'avoir de meilleur schéma explicatif de la compilation/interprétation (version libre sur le net ?) === Et Java ? === * La version 1.7 est reportée à 2009 * Remplacer //Servlet// par //JSF// qui tend à s'imposer et qui cache les //servlets// * p20 : //Jouit d'un succès croissant// est mis comme élément de //qualité pédagogique// ce qui n'a rien à voir -> faire un deuxième point : //S'est imposé en milieu professionel// * p21 : Dans //Autres// ajouter //Application Dsitribuée (pour les gestions)// === Objectifs, moyens et évaluations === * Inutile de trop s'y attarder; les choses peuvent fort évoluer. On verra en début d'année. * Un ouvrage de référence commun que les étudiant devraient avoir (on y ferait "référence") --DNA > On peut proposer "The Java Language Specificatation", c'est un livre de référence. --Pbt > Je pensais plutôt à celui-ci "//Programmer en Java//" de Claude Delannoy --DNA === Développer en Java === * Des plus beaux schémas seraient un plus... === Survol du langage === * MCD : A propos des types de base. On s'est limité à un type par type logique mais on a retrouvé les autres types dans nos exemples par la suite (float, long, ...). Il faudrait se positionner. * soit on est strict et on ne cite pas les autres types (je ne pense pas qu'ils sont nécessaires d'ailleurs; leurs présences est probablement plus dues à de la distraction) * soit on ajoute un slide où : on les cite; on dit qu'ils divergent par la taille des valeurs représentées; on préconise les autres pour un usage courant * Je suis d'avis de les citer à un moment ou à un autre et de n'utiliser que int et double **sauf** quand c'est bien de parler des autres pour être complet (je pense aux Wrappers par exemple) --Pbt * MBA - Moi je nettoyerais les distractions. Pour le début on peut qd même se contenter de int char double String. * MCD : Lecture des données. Dans les TDs, le hasNext() leur est utile. On peut peut-êtrre l'ajouter. * MCD : le for. On ne donne pas l'exemple du //for (**int** i...// alors qu'on l'utilise souvent par la suite. A nouveau : faire un choix et s'y conforter ! * MCD : try/catch. On montre comment attraper mais pas comment lancer. Idée louable car c'est plus complexe mais il y a des cas fréquents où ce n'est pas compliqué (vérification des paramètres) -> j'ajuterais le //throw new IllegalArgumentException()// après avoir parlé des fonctions * p111: on peut sans perte de sens enlever tous les exemples avec autre chose que //int// ou //double//. === Notion de grammaire === * RAS === La grammaire Java === * RAS === OO === * MCD : Je pense qu'il faut retravailler un peu l'ordre des slides. * On donne bcp d'exemples de Rectangle mais on ne peut le tester en machine qu'à partir du 32ème slide (et la définition du constructeur avec paramètres). C'est dommage car c'est un chapitre qui demande à passer du temps sur linux1 à montrer les choses. * Je me demande si cela ne vient pas de l'idée, louable, de mettre directement des exemples avec attributs privés sans commencer par un version non recommandée aux attributs publics. Car alors tout est dans tout et c'est difficile de trouver l'angle d'approche. MBA - non svp je n'aime pas du tout l'approche d'abord tout public ... === Les tableaux === * MCD : La version actuelle présente les tableaux à 1 dim et plusieurs dim en même temps et procède notion par notion en étant à chaque fois très précis ce qui fait que les exemples complets arrivent tard. Je me demande si il ne vaudrait pas mieux commencer par une approche uniquement 1 dim sans les cas particuliers afin d'avoir tout de suite quelques exemples et puis repasser tout en détail et dans toutes les dimensions. === Les collections === * MCD : J'avais avancé ce chapitre ici pour rester en phase avec Logique qui voit les Listes et les listes ordonnées. Et je me suis dit : "tant qu'à faire passons en revue toutes les collections" mais on s'est bien rendu compte que ce n'est pas si simple. * En plus, ils n'ont pas l'occasion de tester cela au labo * -> proposition : ne voir que ArrayList et laisser le reste pour le second semestre (ce qui laisse du temps pour avancer une autre partie au premier semestre; quoi ?) * MBA : est-ce que ça ne per pas son intérêt ? * MBA : exercice à incorporer : parcourir un tableau à 2 dimensions avec deux foreach imbriqués :-) Si c'est ici qu'on voit le foreach. === Type et littéraux === * A suivre... === Expressions === * A suivre... === Conversions=== * à compléter : conversions de type référence (au moins les notions de narrowing - widening), Boxing, Unboxing ... -- MBA * petit exemple de code pour illustrer la perte de précision dans la conversion entier -> flottant (widening) -- MBA final long START = 999999999999999999l; /* premier nombre de la série */ double elargi; long grand, grandDeRetour; for (grand = START; grand