Que devient la programmation OO ? - Page 3

"Enfin bon il faut voir aussi que ce qui freine énormément l'adoption de Java/C# pour l'instant, c'est que la VM est très lourde (surtout dans le cas de Java) et c'est long à télécharger (surtout dans le cas de C#, où en plus personne ne l'a). Ce qui fait que c'est surtout utilisé dans des gros serveurs en entreprise..."

Lourd, les runtimes pour les 2 langages fontle meme poids.

les accesseurs automatiques ne sont pas gérés en Java, et je préfère.

moui pour ce que je comprends de la programmation, je trouve que c'est bien de laisse le choix. Un accesseur étant pour moi un moyen de contrôler les valeurs d'une affectation, je trouve que ce n'est pas toujours nécessaire.

alexis :
les accesseurs automatiques ne sont pas gérés en Java, et je préfère.

Moi c'est le contraire. C'est ma perception, mais je trouve que ça cadre bien avec la philosophie pure OO : lorsque le programmeur veut accéder à l'une des propriétés d'une classe, je trouve ça pratique de pouvoir y accéder directement par son nom, sans avoir à utiliser un accesseur, que la valeur de cette propriété soit celle d’un attribut ou le résultat d’un traitement.

Encore une fois, ça reviens au même d'appeler explicitement des méthodes et ce n'est pas pénalisant, c'est juste pour le programmeur que ça change quelque chose.

Bien sûr, en Moka ce n'est pas supporté.

squalyl^2 :
moui pour ce que je comprends de la programmation, je trouve que c'est bien de laisse le choix. Un accesseur étant pour moi un moyen de contrôler les valeurs d'une affectation, je trouve que ce n'est pas toujours nécessaire.

Bien sûr que c'est pas toujours nécessaire.
Le pb, c'est que s'il n'y a pas de propriétés, alors tu vas avoir une distinction au niveau de la syntaxe entre les deux (dans le code qui utilise ta classe), et donc, plus tard, tu ne vas plus pouvoir changer pour mettre un accesseur, sinon ça casserait le code. Et donc t'es bien dans la merde

Pollux
:

squalyl^2 :
moui pour ce que je comprends de la programmation, je trouve que c'est bien de laisse le choix. Un accesseur étant pour moi un moyen de contrôler les valeurs d'une affectation, je trouve que ce n'est pas toujours nécessaire.

Bien sûr que c'est pas toujours nécessaire.
Le pb, c'est que s'il n'y a pas de propriétés, alors tu vas avoir une distinction au niveau de la syntaxe entre les deux (dans le code qui utilise ta classe), et donc, plus tard, tu ne vas plus pouvoir changer pour mettre un accesseur, sinon ça casserait le code. Et donc t'es bien dans la merde

C'est pourquoi j'aime bien les accesseurs automatiques. C'est plus transparent.

je ne connaissais pas les accesseurs automatiques (je ne fais pas de cpp). Donc quand on en écrit un, on override l'appel automatique à l'accesseur du champ? c'est pas con.

Que de truc que je lit ici


Alors
1 -> l'OO ne fonctionne pas forcement par dessus une machine virtuelle :/ le C++ compile du code natif hein !

2 -> Arretez vos bétises, de l'OO est tres courrement utilisé dans l'embarqué ! ça passe du PDA, au telephone portable, au lecteur de DVD de salon, chaine hifi, ...., bref de partout et ce de plus en plus (surtout du C++ hein)

3 -> Java trop lourd ? Ben alors expliquez moi pourquoi il existe une machine virtuelle java pour 68HC11 ??? et celle-ci fonctionne avec 32Ko de ram, oui 32Kilo Octets !!, bon certe c'est un peu exagéré la et il reste pas bcp de place pour les programmes utilisateurs, mais bon, ça rame pas, ça marche tres bien, tte la lib standard java est pas implémenté c'est sur, mais bon sur une machine avec 32Ko de ram, un ecrant 2x15 caractere on s'en fou un peu de tte la partie graphique n'est-il pas ?

Bref du C++, du smalltalk, de l'Objective C & co peuvent tres bien fonctionner sur un 68000 @ 10/2Mhz

D'ailleurs, le smalltalk existait deja bien avant 1984 vu qu'il est a l'origine du dévelopement de l'Alto, la premier (ou presque) machine proposant une interface graphique avec un dispositif de pointage, la souris

Godzil > "l'OO ne fonctionne pas forcement par dessus une machine virtuelle :/ le C++ compile du code natif hein !" Ca on le sait, enfin ca depend qui. Tu n'as pas besoin d'aller chercher du C++ le Java se compile avec gcj.
Godzil > "Arretez vos bétises, de l'OO est tres courrement utilisé dans l'embarqué" > Je suis bien d'accord, mais les machines virtuelle de PDA, telephone portable ou de lego mindstorm voir ti n'ont rien a voir entre elles.

Pour une ti, je trouve qu'une machine virtuelle c'est trop lourd et dans le cas contraire ca ne sert pas a grand car trop restrainte. Chacun sa vision des choses, ca va marcher bien sur, mais ca ne sera pas intéressant!

En ce qui concerne le vrai embarqué (et non pas le mobile ou il y a maintenant une JVM dans presque cahque matériel mobile), j'ai eu la chance de pouvoir faire du java embarqué pour piloter un robot mindstorm, et on va dire que les contraintes de programmation n'ont rien à voir, et ca ne sert pas a grand chose de confronter les deux mondes.

Le c++ peut très bien marcher sur une platte-forme telle qu'une ti, mais est-ce que ca en vaut vraiment la peine?

squalyl^2 :
je ne connaissais pas les accesseurs automatiques (je ne fais pas de cpp). Donc quand on en écrit un, on override l'appel automatique à l'accesseur du champ? c'est pas con.

Exemple de cas : j'ai un char (i.e. une automobile) qui a de nombreuses propriétés, dont la consommation d'essence, la capacité du réservoir et le kilométrage que je peux faire par plein.

En Java (ou en Moka), une implantation minimale ressemblerait à ça :

public class Voiture {
  public int consomation ; // En l / 100 km
  public int capacite ;
  public int kmParPlein ;
}

Habituellement, on ajoute un constructeur :

public class Voiture {
  public int consommation ;
  public int capacite ;
  public int kmParPlein ;

  public Voiture (int parConsommation, int parCapacite, int parKmParPlein) {
    this.consommation = parConsommation ;
    this. capacite = parCapacite;
    this. kmParPlein = parKmParPlein;
  }
}

Le programmeur accède aux propriétés en manipulant directement les attributs :

int km = monChar.kmParPlein ;

Là, c’est pas très recommandé, car je peux accéder directement aux attributs (ils sont publics), alors je les met privés et je fourni des accesseurs – autrement dit, je les encapsule :

[…]
  private int consommation ;
  private int capacite ;
  private int kmParPlein ;

[…]

public int getKmParPlein () {
  return kmParPlein;
}

public int setKmParPlein (int km) {
  this.kmParPlein = km;
}

[…]

Le programmeur accède aux propriétés via les accesseurs :

int km = monChar.getKmParPlein() ;

De cette façon, je peux changer l’implémentation sans qu’il n'y ait d’impact sur lui.  Exemple, je décide de calculer la valeur de kmParPlein, au lieu de la conserver :

[…]

public int getKmParPlein () {
  return this.capacite / this.consommation * 100;
}

public int setKmParPlein (int km) {
  this.consomation = this.capacite * 100 / km;
}

[…]

Avec des accesseurs automatiques, le programmeurs accèdent aux propriétés comme s’il s’agissaient d’attributs, peut importe qu’ils soient encapsulés ou non :

J’accède à ma propriété comme suit :

int km = monChar.kmParPlein ;

ou

monChar.kmParPlein = km ;

Si ce sont des attributs publiques et qu’il n’existe pas d’accesseur, on y accède directement, sinon on invoque l’accesseur (set / get).

Godzil :
Que de truc que je lit ici

Je suis d'accord avec ce que tu dis, je suis en faveur des langages OO sur calculatrice, mais nous, tout ce que l'on dit, c'est que les préocupations sur TI68K ne sont pas les mêmes que sur un micro ordinateur.

alexis :
Godzil > "l'OO ne fonctionne pas forcement par dessus une machine virtuelle :/ le C++ compile du code natif hein !" Ca on le sait, enfin ca depend qui. Tu n'as pas besoin d'aller chercher du C++ le Java se compile avec gcj.

Le java ne se compile pas de maniere OFFICIELLE en natif alors que le C++ compile TOUJOURS en natif

D'ailleurs il existe des langage procéduriers qui fonctionnent par dessus une VM, Interactive C (http://www.handyboard.com) par exemple est un langage C (plus ou moins édulcoré mais c'est quand meme du C a la base) fonctionne par dessus un machine virtuelle..

Cette agglomération OO/VM me tape sur les nerf..

VM != OO
VM != OO
VM != OO
VM != OO
VM != OO
VM != OO
VM != OO
VM != OO

Godzil > "Arretez vos bétises, de l'OO est tres couramment utilisé dans l'embarqué" > Je suis bien d'accord, mais les machines virtuelle de PDA, telephone portable ou de lego mindstorm voir ti n'ont rien a voir entre elles.

Tu viens pas de dire plus haut que l'OO ne dépend pas d'une machine virtuelle ? Alors pourquoi tu en parle

Tu te contredis..

et je n'ai JAMAIS parlé d'utilisation de machine virtuelle pour ce genre de machines

et d'ailleur de quelle machine virtuelle tu parle ? qui execute quoi comme code ?

Forcement si tu parle d'une JVM pour un tel, d'Interactive C pour du mindstorm et de .NET pour PDA c'est sur que ça a rien a voir

Si par contre du parle d'un JVM pour un tel, d'un JVM pour un mindstorm, d'une JVM pour un PDA, la tu raconte n'importe quoi, si on parle de JVM c'est que la VM execute du bytecode JAVA ! pas du bytecode .NET

Pour une ti, je trouve qu'une machine virtuelle c'est trop lourd et dans le cas contraire ca ne sert pas a grand car trop restrainte. Chacun sa vision des choses, ca va marcher bien sur, mais ca ne sera pas intéressant!

J'en rajoute une couche "machine virtuelle gna gna gna"

En ce qui concerne le vrai embarqué (et non pas le mobile ou il y a maintenant une JVM dans presque cahque matériel mobile), j'ai eu la chance de pouvoir faire du java embarqué pour piloter un robot mindstorm, et on va dire que les contraintes de programmation n'ont rien à voir, et ca ne sert pas a grand chose de confronter les deux mondes.

du java sur une brique RCX ? je demande a voir, sachant que les contraites du RCX sont supérieurs a celle de l'handyboard (- de mémoire, proco globalement plus restreint..)

Le c++ peut très bien marcher sur une platte-forme telle qu'une ti, mais est-ce que ca en vaut vraiment la peine?

Oui ça peut

Quesoft
:

Godzil :
Que de truc que je lit ici

Je suis d'accord avec ce que tu dis, je suis en faveur des langages OO sur calculatrice, mais nous, tout ce que l'on dit, c'est que les préocupations sur TI68K ne sont pas les mêmes que sur un micro ordinateur.

Je parlait pas spécirfiquement des TIs, mais de l'OO en général

Il a été affirmé dans la page 1 si j'ai de bon souvenir que l'OO sur ti est pas possible pasque vm, et vm trop lent gnagnagna

et bien sur personne ne lui a répondu

d'ailleur pour reprendre certaines pensées de Pollux (pas sur ce topic) je suis persuadé qu'une VM bien faite serait plus efficiente que du natif sur une TI

Godzil :
Il a été affirmé dans la page 1 si j'ai de bon souvenir que l'OO sur ti est pas possible pasque vm, et vm trop lent gnagnagna

Là dessus c'est clair que tu as raison : OO != VM, je suis surpris de ne pas avoir répondu au post dont tu parles...

Godzil :
d'ailleur pour reprendre certaines pensées de Pollux (pas sur ce topic) je suis persuadé qu'une VM bien faite serait plus efficiente que du natif sur une TI

Peut-être, mais malheureusement, la seule VM qu'on a (waba), à ma connaissance, ne donne pas le change...

pasqu'il s'agit en l'occurence d'un portage de qq chose de deja existant (et je sais ce que ça donne de porter directemetn du code C PC vers du C pour TI, c'est lent, gros, pas bo.. et oui en plus un emulateur n'est rien d'autre qu'une machine virtuelle)

le pbm c'est que pour avoir qq chose de vraiment au top il faudrait ecrire la VM de 0 (ou presque) meme si cela n'empeche pas de respecter une "norme" tel celel de java ou la CLR. Si java et la CLR sont aussi gros et "lent" c'est simplement pasqu'elle sont faites pour fonctionner sur des os "gros" et "lent", sur ti on a la chance de pouvoir develloper 100% en ASM (et c'est quand meme cvalable pour le C de tte maniere) sans avoir a se faire chier a parler a un OS qui s'occroit tout et donc par qui on doit passer pour avoir la moindre chance de pouvoir faire quelque chose.


D'ailleur un systeme a base de VM et d'OO qui pourrait etre porté sur TI, serait SmallTalk, un vm avec son GUI peut etre allégé de maniere impressionante tout en restant utilisable

bref

Godzil :
D'ailleur un systeme a base de VM et d'OO qui pourrait etre porté sur TI, serait SmallTalk, un vm avec son GUI peut etre allégé de maniere impressionante tout en restant utilisable

bref

C'est possible. Cependant ça représente beaucoup de travail. En plus, j'ai un préjugé favorable envers les programmes natifs.

J'avais choisi de faire un convertisseur parce que c'était plus facile à implémenter et qu'en plus, lorsque TIGCC supportait une nouvelle fonctionnalité, Moka pouvait la supporter sans trop de modification (une petite mise à jour de l'API ou directement, en utilisant les mécanismes d'interopérabilité).

Il serait intéressant de voir démarrer un projet de la sorte ...

mais bien organisé et pas une seule personne, sinon ca avancera jamais.

squalyl^2 :
mais bien organisé et pas une seule personne, sinon ca avancera jamais.

Sûr.

Une VM rame toujours.

Non.

Non kevin au lien de lancer des flameware sur tout ce que tu connais/comprend pas et que tu deteste renseigne un peu

"et je n'ai JAMAIS parlé d'utilisation de machine virtuelle pour ce genre de machines " >> La c pour moi, j'ai lu un peu vite ce que tu avais marqué...


En ce qui concerne les PDA, je ne te parle pas de .net, oui il y a des PDA avec des JVM >> la JVM J9 d'IBM pour Pocket PC(CDC), Palm(MIDP 2.0), ZAURUS(CDC également), JEODE et CREME également pour PPC. Donc je ne parlais pas de .net et donc bien de JVM pour PPC.


>> Le java ne se compile pas de maniere OFFICIELLE en natif

Oui c parce que SUN l'as décidé comme ca, la JVM fait office de sandbox, ils auraient pu faire sans, c'est à dire en compilant pour la platte-forme, mais l'idée était compile once, run everywhere. Je trouve une VM non pas principalement pour cette raison, mais plutot parce qu'elle agit en tant que sandbox, et offre des fonctionnalités étendues. Le moins dans tout ca c la vitesse bien sur, je suis d'accord. Quoi que le résultat, me satifait pas mal.


>> du java sur une brique RCX ? je demande a voir, sachant que les contraites du RCX sont supérieurs a celle de l'handyboard (- de mémoire, proco globalement plus restreint..)

Désolé pour toi Godzil, mais ca existe puisqu'on en a fait en cours... et ca tourne plutôt bien dessus.
En plus c du JAVA RT! ...
http://java.sun.com/features/2002/05/robot.html
http://www.pangloss.it/libro.php?isbn=1928994555&id=10026



Pourquoi je parle autant de machine virtuelle et (ce qui a l'air de t'énerver profondemment)? au cas ou tu ne l'aurais pas remarqué, les JAVA(J2SE et J2ME), .NET sont basés dessus, et pour moi ce sont un peut plus que des poids lourds... et surtout c'est ce qui est le plus utilisé aujourd'hui en entreprise

Alors apres pensez ce que vous voulez, mais si MICROSOFT, IBM, et SUN proposent des solutions à base de VM et en font les cheval de bataille, il doit y avoir de raison.

Ceci n'enlève C/C++ par exemple leur utilité et leur spécificaté. Je ne dénigre rien à ce sujet.

alexis
: Alors apres pensez ce que vous voulez, mais si MICROSOFT, IBM, et SUN proposent des solutions à base de VM et en font les cheval de bataille, il doit y avoir de raison.

Effectivement, il y a une raison, mais pas forcément technique : commerciale par exemple.

alexis :
>> du java sur une brique RCX ? je demande a voir, sachant que les contraites du RCX sont supérieurs a celle de l'handyboard (- de mémoire, proco globalement plus restreint..)

Désolé pour toi Godzil, mais ca existe puisqu'on en a fait en cours... et ca tourne plutôt bien dessus.
En plus c du JAVA RT! ...
http://java.sun.com/features/2002/05/robot.html
http://www.pangloss.it/libro.php?isbn=1928994555&id=10026

Mouais euh faut pas déconner c'est pas du Java mais du ««« Java »»» : "One of the things that the developers of leJOS haven't been able to do yet is to include garbage collection." (et il manque sûrement d'autres choses, j'ai pas lu tout l'article)
Ca ressemble peut-être en apparence à du Java, mais c'est tout sauf un langage de haut niveau

alexis> mais bien sûr, j'aime beaucoup ton raisonnement. MICROSOFT pense pour vous IBM pense pour vous, SUN pense pour vous. Laissez-vous guider. Jusqu'où irez vous ?

Pollux> il faudrait commencer par définir ce qu'est du haut niveau. Parce que pour moi le c++ est du haut niveau.

Par contre oué c'est vrai le truc là c'est un sous-ensemble de Java. C'est ça le problème, il y a tellement de concepteurs qui implémentent des sous-ensembles de Java que à la fin le code n'est plus portable entre les systèmes se disant Java.

Pollux
:

alexis :
>> du java sur une brique RCX ? je demande a voir, sachant que les contraites du RCX sont supérieurs a celle de l'handyboard (- de mémoire, proco globalement plus restreint..)

Désolé pour toi Godzil, mais ca existe puisqu'on en a fait en cours... et ca tourne plutôt bien dessus.
En plus c du JAVA RT! ...
http://java.sun.com/features/2002/05/robot.html
http://www.pangloss.it/libro.php?isbn=1928994555&id=10026

Mouais euh faut pas déconner c'est pas du Java mais du ««« Java »»» : "One of the things that the developers of leJOS haven't been able to do yet is to include garbage collection." (et il manque sûrement d'autres choses, j'ai pas lu tout l'article)
Ca ressemble peut-être en apparence à du Java, mais c'est tout sauf un langage de haut niveau

Ha tiens j'avais pas vu ce point

http://www.rtjcom.com/6811/general.html#features

et spécifiquement a la handyboard :

http://www.rtjcom.com/6811/hb.html

Specially optimized to run on the embedded systems with limited memory resources (from 48KB). On average the simpleRTJ will not require more than 18-23KB of code space to run.

Designed to run as a stand-alone miniature Java operating system. No other RTOS is required to be present in the memory.

Implemented thread support with object's monitor locking and wait/notify synchronization. A timer interrupt should be available to provide VM with time base for the pre-emptive time sliced thread scheduler.

Uses optimized java.lang package to preserve small memory footprint of the Java applications.

Implements support for the javax.events package. This package allows to handle responses to asynchronous events (some interrupts, comms, keypad,...) in Java code. Also included are classes for creating software timers (single shot and periodic).

Supports String and StringBuffer objects.

Exception handling is fully implemented.

Interfaces are fully supported.

Multidimensional arrays are supported.

Includes compacting, three color mark & sweep automatic garbage collector.

Uses simplified native interface to provide fast invocation time for the native methods.

Large number of startup configuration options for specifying the heap size, number of references, threads, software timers, etc.

The simpleRTJ code can be built separately from the native code. This feature allows VM to be programmed into the EPROM/FLASH and the native code and Java application loaded into the RAM when needed.

Number of compilation options allow to control the size of char data type, inclusion of floating point, presence of garbage collector, etc. These options can be used to tailor VM to specific needs of the target platform and the Java applications. 

Supports the following memory models:
- linear 64KB
- banked 64KB
- linear up to 16MB

Can execute Java applications of up to 16MB in size


Limitations

Java language package java.lang was optimized (minimized) to include only classes and methods that are relevant to this implementation of the Java VM.

64-bit double and long arithmetic is not supported

Divide ( / ) and modulo ( % ) operators works at the moment only on 16-bit numbers.

Thread support doesn't yet provide synchronization on synchronized methods and code sections. java.lang.Object class doesn't implement thread synchronization methods wait and notify.

Multi-dimensional arrays are not supported.

Performance of the application written in Java and run under VM is slower than applications written in C. This limits the use of Java VM to applications which do not require fast responses from the control program. However, interrupts are are always serviced as soon as they are registered by the processor. Furthermore, it is always possible to write time critical operations in the native code and that way balance the slower execution of the main program.
JNI is not supported. Instead, there is a simple and fast native interface provided.

spectras>
Ben le problème c'est que le C++ est *conçu* pour ne pas être garbage collecté (cf libération automatique en sortie de scope, références et pointeurs...), donc c'est pas vraiment problématique qu'il ne le soit pas. Alors que le Java, c'est pas du tout, mais alors pas du tout fait pour être utilisé comme ça : résultat, tu dois gérer la mémoire exactement de la même manière qu'en C, voire pire : alors qu'en C tu peux copier tes chaînes dans des buffers déjà alloués sur la pile (donc rien à libérer), en Java non garbage-collecté tu *dois* libérer manuellement n'importe quelle chaîne que tu utilises (y compris celles qui sont utilisées temporairement), et au bon moment... Ce qui fait qu'on se retrouve avec un langage encore plus bas niveau que du C

Godzil> ben là pour le coup c'est intéressant, si ça s'interface bien avec le C et que la lib standard n'est pas trop vide

pourtant dieu sait que le C est tres bas niveau comme langage

Pollux :
Godzil> ben là pour le coup c'est intéressant, si ça s'interface bien avec le C et que la lib standard n'est pas trop vide

C'est a priori le cas, bon certe sur un 68HC11 c'est quand meme limité hein ^^

Mais ct la vm java dont je parlait, que j'ai testé et qui marche du feu de dieux

Il me semble d'ailleur que cette vm existe en version 68K..

a voir