SIMULER LA VISIBILITÉ PACKAGE (COMME EN JAVA)
LocalStone
Messages postés
514
Date d'inscription
mercredi 19 mars 2003
Statut
Membre
Dernière intervention
1 mars 2009
-
7 juil. 2007 à 10:33
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 2 mars 2009 à 19:06
verdy_p Messages postés 202 Date d'inscription vendredi 27 janvier 2006 Statut Membre Dernière intervention 29 janvier 2019 - 2 mars 2009 à 19:06
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/43361-simuler-la-visibilite-package-comme-en-java
https://codes-sources.commentcamarche.net/source/43361-simuler-la-visibilite-package-comme-en-java
2 mars 2009 à 19:06
- du côté de la programmation massivement parallèle (sur le GPUs par exemple dans OpenGL et DirectX, qui deviennent programmebles de façon génériques avec des langages spécialisés)
- du côté des webservices et hébergements virtualisés (on parle de "thin client" et de "cloud computing"
- du côté du calcul distribué
- du coté des fondeurs de processeurs qui se sont lancés dans la bataille de la virtualisation.
- du côté de Microsoft qui défend encore sa voie .net et va tenter de l'imposer dans Windows 7 tout en promouvant sa plateforme VM ware (largement critiquée pour son surcoût exhorbitant en performance et son incapacité à supporter de nombreux coeurs ou le calcul massivement parallèle)
- les efforts faits par Sun et IBM pour créer un remplacement à son bytecode actuel pour Java (insuffisant et difficilement paralélisable et ne permettant pas de supporter tous les langages actuels ni d'offrir une interopérabilité totale avec dot.Net:
http://www.dotnetguru.org/modules.php?op=modload&name=News&file=article&sid=321&mode=thread&order=0&thold=0
(le but de ce projet est de créer une VM universelle)
Les compilateurs natifs sont en cours de tuning mais le but est bien de masquer l'architecture actuelle de la machine afin de rendre tous lesprogrammes et services déployables partout avec les performances optimales, et de permettre le support de toutes les architectures de virtualisation actuelles (qui seront émulées avec des performances excelentes et optimisées en fonction de la macjhien cible effectivement utilisée).
La virtualisation de tout le logiciel actuel, qu'il soit local ou un service réseau, avec un seul ou de nomberus utilisateurs, que ce soit pour des interfaces graphiques, des applis interactives, ou du calcul scientifique massif, avec une distribution automatique sur toutes les ressources de calcul disponibles dans un environnement hétérogène, constitiuent bien les voies suivies. On devrait aboutir en 2010 vers une version Beta de Java 7 sur cette architecture qui devrait aussi fonctioner comme un hyperviseur capable de supporter divers OS actuels (y compris Linux ou Windows). Du côté d'IBM, il planche avec AMD sur des accélélations matérielles de ce code VM qui deviendrait pris en charge de façon antive par les processeurs 32-bits et 64-bits actuels (il devrait aussi y avoir un support du code natif x86 ou x64 actuel par émulation dans cette VM future).
Evidamment derrière, il y a tout le marché futur des serveurs d'applications, et des services distribués, ou encore du logiciel hébergé comme un service et accessible depuis n'importe quel terminal connecté (du PC au téléphone mobile via les serveurs locaux d'entreprises), avec une échelonnabilité "à la demande".
Windows est clairement menacé, alors que Linux et Unix y voient leur planche de salut. Mais Microsoft prend désormais du retard et ne rient encre que par un marketing aggressif (il est probable qu'à l'avenir Windows deviendra gratuit, ce qui sera payant c'est l'offre de service en ligne pour l'hébergement ou l'interconnexion d'applications et de services). Dès l'année prochaine Java sera prêt alors que Microsoft en sera encore à tenter de mobiliser les entrerprises pour leur passage vers Windows 7 après avri raté l'étape de Vista.
Microsoft se trompe de guerre: l'OS n'est plus une ressources stratégique et ne se défend plus que par son "look" et son utilisabilité, des domaines où Linux et même Apple ont gagné des points, alors que maintenant d'autres plus gros encore que Microsoft se lancent dans la bataille: les FAI et les fournisseurs d'infrastructure réseau (et Google par exemple l'a bien compris); l'avenir ce n'est plus l'ordinateur et ce qu'il a "dans le ventre", mais le réseau, l'interopérabilité, l'accessibilité et l'échelonnabilité à la demande, une meilleure résistance aux pannes, et à un coût global largement inférieur et une administration unifiée et simplifiée), et pour les utilisateurs cela veut dire que l'effort est consenti envers une personnalisation facilitée.
Il faut reconnaitre que de moins en moins de monde s'intéressera à votre capacité à faire du code natif puisque c'est le compilateur intégré à la machine virtuelle qui offrira directement les meilleurs performances et de façon plus rapide et plus aisée à déployer, alors que votre code natif "fait maison" ne survivra pas à la demande de déploiement sur d'autres plateformes plus étendues et aura un cycle de vie de plus en plus court en comparaison du code managé qui verra son cycle de vie augmenter et plus intéressant à utiliser car déployable à plus grande échelle. Hormi les rares qui construisent du matériel (et ils sont de moins en moins nombreux à pouvoir le faire tant les coûts de recherche ont explosé), on aura moins intéret à faire de l'assembleur, du C, alors que le code managé sur VM (en C#/dot.net, Java, Python, ...) prend de plus en plus de valeur.
Note: Java a été porté en interne chez Sun sur plateforme VM .Net (au lieu des plateformes natives), mais c'est une étape intermédiaire pour porter le tout vers la VM universelle. Le débogage est en cours, et de nombreux JSR incluent le support des possibilités offertes par les futures VMs sur diverses plateformes; du côté applicatif, on s'oriente vers l'API unique, mais des implémentations plus nombreuses de la VM, masquant leurs diférences pour que le même code ou service soit accessible le plus possible depuis n'importe quel point même s'il n'est pas totalement exécuté localement.
2 mars 2009 à 18:01
Evidemment il faut se faire à un léger changement de syntaxe: plus de point virgule pour séparer les instructions, mais une instruction par ligne (ou sinon un ":" pour indiquer que la suite de l'instriuction est formatée en bloc), plus d'accolades (les blocs sont indentés à la place, ce qui pousse au moins tous les programmeurs à indenter leur code correctement, rend le code lisible, et permet d'éviter les bogues relatifs aux mystérieux point-virgules ou accolades en trop ou mal appairés et corrigés ensuite de façon incorrecte.
Certains critiquent cette écriture, mais pour ceux qui veulent la syntaxe C/C++/Java classique, elle est possible dans une variante de Python compatible avec sa VM.
Le gros intéret de Python on écrit le code et on peut l'exécuter immédiatement, sans compilation préalable (la compilation est automatique, la VM compile juste ce qui est utilisé et maintient un cache dans des fichiers ".pyc"); il est même possible de modifier un source ".py" pendant son exécution (et forcer Python et relire une classe dès qu'elle cesse d'être utilisée).
Le démarrage de la VM Python est assez rapide, mais peut aussi consommer autant de mémoire que celle pour Java, il n'y a pas de vraie différence entre les deux à l'heure actuelle (la lourdeur apparente de Java tient au fait qu'on l'a trop vu utilisée pour exécuter des Applets web qui nécessitent un environnement assez lourd à initialiser, et de nombreuses librairies, alors qu'elles ne sont pas nécesaires absoluement à Java. Un script Java peut être aussi économe (mais il est dommage que la VM de Sun ne prenne pas en charge automatiquement la compilation des sources, ce que peuvent faire d'autres VM Java. De plus trop de gens ont connu Java du temps de Microsoft qui l'a rendu très lent et même incompatible, alors que depuis HotSpot dans Java 2, les performances n'ont plus rien à voir; aujourd'hui dans Java 5 on est loin de ce mauvais souvenir, Java est très rapide et bat pratiquement toujours .Net en performance comme en consommation de ressources mémoire, et en vitesse transactionnelle dans une contexte multithread ou multicoeur voire multiprocessus ou via des instances d'interfaces proxies de services réseaux); en performance brute sur des environnements hétérogènes, le même code obtient pratiquement les performances optimales de chaque architecture matérielle alors qu'un code compilé en C/C++ ou même C# ne se déploie de façon optimale que sur un nombre restreint de plateformes (aileurs les performances sont très mauvaises). Pour vous en convaincre, regardes la très grande lourdeur de l'interface graphique de Vista, toute en .Net, mal optimisée et qui consomme une grande quantité de ressources, et comparez à l'interface graphique de MacOSX qui contient une VM JAva presque invisible...
Le modèle de compilation dynamique à la demande (partiellement implanté dans Java qui demande une précompilation du bytecode, et dans Python à qui il manque encore le profilage à l'exécution pour la prédiction de branchement, pour l'allocation hiérarchisée des registres les plus rapides, et le regroupement relatif du code dans des pages mémoires plus localisées avec un meilleur taux de succès dans les caches matériels) est la solution d'avenir.
Il y aura encore du C ou du C++ voire de l'assembleur dans une partie des pilotes matériels du système hôte, mais de plus en plus de code sera virtualisé et optimisé localement à la demande selon le profil d'utilisation et de déploiement.
Il est même probable qu'une grande partie du code C ou C++ actuel sera compilé vers cette machine virtuelle (dans une forme modifiée, dite "managée") au lieu du code natif puisque cette dernière phase sera prise en charge séparément en fonction des capacités matérielles du système exécutant effectivement le code et qui peut être différent même de l’hôte du contrôleur général du système sur lequel l'application est installée, déployée ou utilisée.
2 mars 2009 à 17:21
Tous les problèmes que tu énonces concernant le PHP, je ne m'en rendais pas compte avant : c'est depuis que je fais du JEE assez avancé que je me rends compte à quel point le PHP est un langage bancal. Mais il a comme énorme avantage d'être moins gourmand et il nécessite beaucoup moins de machinerie que le Java. Il me faut au moins 10min pour faire un Hello World! en JEE et moins de 10sec pour le PHP.
Du coup, tout comme toi, j'ai cherché une alternative entre le JEE et le PHP et c'est tout naturellement que je me suis intéresse au Ruby. Mais j'ai pas eu le temps de faire plus que de lire 2 ou 3 tutos et quelques comparatifs de derrières les fagots.
Mais tu viens de me convaincre pour le Python. Pas mal de gens disait que c'était vraiment puissant et bien fait, mais j'ai trouvé une communauté moins active que pour le Ruby (mais ai-je seulement bien cherché cette communauté :P).
2 mars 2009 à 16:58
Ayant découvert Python tardivement j'ai été surpris par la grande rapidité d'apprentissage de ce langage (même si j'en connaissais déjà de nombreux): je me suis plus vite mis à Python que de me remettre à PHP que je connaissais avant. Et Python reste dans la ligné de Java ou C++ en terme de philosophie générale et de modélisation objet.
Il me semble que comme langage de script il n'y aaujourd'hui pas mieux: c'est aussi rapide à développer que le PHP, aussi souple que le Javascript, aussi solide dans son typage que Java, la librairie de base est aussi riche que celle de Java (sans les multiples variantes incomplètes dans la librairie PHP de base), et s'enrichie plus vite dans ses extensions, sa syntaxe est légère (fini les "$" inutiles dans le code source PHP), et en plus son moteur est maintenant très rapide aussi avec sa machine virtuelle qui génère du bytecode précompilé (comme Java et .Net), mais aussi du code natif profilé à l'exécution (comme java aussi, mais pas encore .Net qui ne fait que du profilage à l'installation et manque de "mobilité").
J'ai bien essayé aussi Ruby, mais sans conviction: les améliorations sont inutilement compliquées, et il lui manque trop de choses dans ses librairies (Ruby est peut-être trop jeune, mais il prend du retard face à Python apparu pas si longtemps que ça avant).
Et Python est déjà près pour le parallélisme massif (le même langage peut servir de langage de kernel pour calcul sur GPUs divers ou sur nuage de coeurs de processeurs locaux ou distribués en réseau, comme sur des threads d'un monocoeur ou des taches sur des serveurs distincts, sans en faire dépendre la granularité arbitrairement par la structure et le découpage de l'application).
Il ne lui manque plus grand chose (dans son bytecode reconnu par sa VM) pour devenir un langage système à part entière: ce qui lui manque c'est un dispositif d'isolation et une architecture de sécurité (comparable à celle dans les ClassLoaders de Java, y compris en terme de vérifiabilité du bytecode et des contrats associés, puisque Python supporte aussi la réflection et une interface simple au code natif de l'hôte).
2 mars 2009 à 16:29
En lisant ton commentaire on aurait envie de bruler tous les codes PHP et de changer de language :))) (lol).
Attention, âmes sensibles s'abstenir !!!
J'ai lu pas mal de remarques de ce type, avantages / inconvénients. La tienne fait sans doute pencher la balance, surtout que tout ce que tu dis est super bien argumenté (ou l'était dans php4).
Merci pour ce commentaire très constructif.
2 mars 2009 à 16:10
Ton code ne gère que l'accessibilité, au prix d'une vérification couteuse à l'exécution, mais pas du tout la visibilité (ce qui signifie que si une classe interdite est visible par ton procédé, elle masquera et empêchera l'accès à une classe autorisée (avec "package" en Java: il n'y a pas d'interdiction c'est la visibilité qui résoud cela; c'est vrai qu'en plus le ClassLoader de Java vérifie les conditions d'accessibilité lors du chargement des classes souhaitant en utiliser d'autres ou des méthodes de visibilité package, mais on peut encore passer outre par un appel indirect via Réflection, une fonction très utile pour les débogueurs qui font grznd usage de Réflection.)
Aussi le titre de ton source va sembler trompeur: il ne s'agit pas de gérer la "visibilité" package mais seulement "l'accessibilité" puisque ton source ne permet pas du tout de rendre invisible une classe instanciée ou héritée ou une méthode ou un champ de cette instance selon le contexte d'usage.
L'invisibilité c'est autre chose: il s'agit de déterminer si la surcharge d'un élément lexical est autorisée ou non (les élements "finaux" ne peuvent pas être surchargés lorsqu'ils sont visibles, ce qui est indpendant de leut accessibilité) et comment se fait cette surcharge (il n'y a pas virtualisation d'une classe de base si la surcharge est invisible, ce qui fait que la classe de base n'est pas modifiée ou peut être modifiée indépendamment de cette surcharge).
En général la visibilité est un aspect du programme source, déterminé par la compilation, mais Java va plus loin en étendant le concept de visibilité à l'exécution (selon un modèle de sécurité implémenté dans le ClassLoader, mais modifiable, justement pour les débogueurs ou pour certaines classes spéciales construisant dynamiquement des proxies ou des entrées/sorties de flux de persistance: dans ces cas là le coût des vérifications par Reflection est négligeable par rapport au coût du débogage ou monitoring lui-même, ou des entrées-sorties réelles; dans les autres cas, la réflexion est trop couteuse et heureusement Java est nettement plus performant pour se passer de ces vérifications faites une seule fois lors du chargement du programme à liaison quasi-statique).
Le but de la visibilité est avant tout d'offrir une liberté de nommage des éléments internes à une implémentation, et sert aussi de modèle de développement. Pour les langages ne supportant pas la visibilité "package" il semble bien plus simple de nommer les classes ou membres de classes avec un préfixe correspondant au nom du package. C'est pas très pratique en terme d'utilisation, mais ça évite le coût de telles vérifications. Pour la visibilité package des classes cela voudrait dire que ces classes devraient toutes être nommées avec de tels préfixes, ce qui n'est pas possible (en revanche en C++ ou C# on a la notion de namespace qui facilite le travail et fonctionne de façon assez proche, quasi équivalente y compris pour la réflexion).
Tant que PHP n'aura pas de réel support pour les namespaces, on ne peut que recommander de prendre garde au nommage des entités (classes, méthodes membres et/ou évènements, champs et/ou attributs, fonctions statiques, variables de classe, constantes déclarées), en adaoptant une convention de nommage (le seul contrôle efficace de visibilité en PHP est celui des variables, mais il est cassé par les constantes définies).
En PHP on doit aussi faire attention aux constantes globales créées avec "define()" qui échappe à tout modèle (comme le font les macros du C/C++) et peuvent même perturber le fonctionnement des classes utilisées de façon inattendue selon l'ordre difficilement prédictible d'inclusion (que ce soit par "include" mais surtout pour "require"): ces constantes globales devraient pouvoir devenir elles aussi invisibles pour éviter les effets de bord, en leur ajoutant aussi la notion de namespace, au minimum; pour le reste PHP dispose de constantes statiques déclarées dans les classes, ce qui devrait suffire à contrôler leur visibilité.)
Personnellement étant passé par Java (ou même C#) après avoir essayé pendant un temps PHP, j'ai énormément de mal à revenir à PHP, tellement le langage est ambigu et très peu propre, et bourré d'anomalies historiques.
J'ai beaucoup moins de mal à passer à Python en revanche, construit sur des bases bien plus solides et selon un principe aussi facile comme langage de script (Pythin est rapidement devenu bien plus puissant que PHP pour cette raison et dispose de librairies et de compilateurs maintenant aussi efficaces que Java ou C# pour .Net).
Et même Perl est plus propre que PHP! C'est peu dire. PHP reste pour moi un langage de prototypage rapide adapté uniquement à la customisatrion légères de sites web (notamement les formulaires), mais gérer de gros projets avec c'est trop risqué (il y a trop de pièges imprévus et le code est difficile à maintenir), PHP est aujourd'hui à Java (ou même Javascript) ce que le Fortran ou le C sont au Pascal ou Modula.
Sa notation sigillaire est également préhistorique ("$" utilisé seulement pour distinguer constantes et variables, sans aucun rôle pour le typage ni la visibilité), ses types de données sont ambigus.
Et même la quasi-totalité de sa bibliothèque de base est ambigue avec trop de fonctions à retour "mixed" dont les types joints ne sont pas séparables.
Les tableaux associatifs de PHP seraient parfaits s'il n'avait pas ce concept interne de position courante, juste là car il est impossible de les gérer comme des références (PHP n'a pas de support correct des itérateurs, le "foreach" est bogué et sujet à divers effets de bord en plus d'être particulièrement couteux en mémoire pour les collections importantes qu'il va copier). PHP ne gère pas non plus la mutabilité (le droit d'accès en écriture séparé de celui en lecture), ni correctement non plus le cycle de vie des instances (Java le fait de façon allégée sans destructeurs mais avec finaliseurs, la destruction restant automatique après finalisation seulement lorsque le besoin de ressources se fait sentir, les opérations qui demandent une finalisation anticipée selon une chronologie bien définie doivent être programmées par des méthodes appelées explicitement, ce qui n'est pas une véritable gène).
PHP en revanche a certains avantages dans quelques contextes, mais tant qu'à faire JavaScript/ECMASCript le fait de façon plus puissante: c'est celui de la modifications dynamique du contenu des objets (tout objet pouvant être la classe modèle d'un autre, il n'y a pas de séparation entre classes et objets, donc pas de complexité relative aux classes, métaclasses, méta-métaclasses... En Java c'est possible aussi mais il faut créer les instances via un ClassLoader qui va aussi créer explicitement la classe proxy (c'est ce que font maintenant implicitement les moteurs Javascript modernes).
Le défaut est que PHP est comme Javascript trop permissif et, ne propose que le renforcement de la visibilité pour les 3 types de visibilité qu'il connait (contrairement à Javascript qui ne propose rien du tout), mais ne fait rien pour renforcer l'accessibilité (ce qui pose de gros problèmes en terme de protection contre l'injection de code, trop facile dans les programmes PHP). Et le support de la généricité est une horreur à programmer et vérifier en PHP (il suffit de voir les listes impressionnantes d'exceptions et de cavéats dans les commentaires sous la doc officielle de PHP, avec divers solutions plus ou moins compliquées de contournements qui ne résolvent qu'une partie du problème, jusqu'à ce que la librairie soit augmentée d'une nouvelle fonction proche qui apporte encore d'autres problèmes! En plus de cela le calcul est largement bogué en PHP et non conforme aux normes de base IEEE que tout langage devrait respecter)
27 janv. 2008 à 21:40
Sinon, une version d'interface permettant de créer ce type de classes ça serais pas mal. Ensuite, afin de simplifier la source, ce n'est pas possible de créer un constructeur du type __construct(&$parent) puis de vérifier que le parent est bien la classe xxx avec is_a($parent, 'classe....').
Puis dans le construct tu peux executer librement les fonctions dont tu fais référence en tant qu'illustration.
Perso moi je créé systématiquement un fonction evtLoad que je surcharge quand j'en ai besoin et elle est dirrectement appellée dans le __construct.
7 juil. 2007 à 10:33