Je me répond a moi même pour en fait répondre a l'ensemble des post du dessu ...
Les termes "naivetée" et "imbécilitée" sont les miens mais il n'attaquaient personne (ou alors tout le monde et moi y compris).
En fait s'ettait plutot pour décrire l'ambiance de la conférence ou les questions commencaient a venir sur le "capitalisme c'est mal", "tous pourri", "c'etait mieux avant" :
Elle a juste rappelé que la colonisation et surtout l'exploitation des richesse des colonies par les pays riches, et dans le _seuls_ interets de c'est dernier, n'avait jamais était abandonné et avait toujours continué sous d'autres formes. (c'est le but même d'un colonie!)
Biens sur que c'est scandaleux et qu'il faut faire quelque chose mais dire que l'on "découvre" le pillage des pays africains c'est surtout prouver que l'on avait fermé les yeux jusqu'a présent.
(et que donc gueuler sur les dirigeant/le systeme c'est rejeter la faute sur un autre car _normalement_ le "systeme" dans un pays démocratique c'est le peuple mais bon c'est un autres débat).
En fait c'etait juste pour relativiser la "_direction_" de la revolte que l'on a apres la vision du film qui ne doit pas vraiment portée uniquement contre le systeme/les politiques/le capitalisme mais plutot contre chacun de nous et contre notre "aveuglement".
j'ai effectivement vu le cauchemard de darwin au cinema et j'ai eu la chance d'avoir une mini-conference a la fin de la part d'une professeurs d'université spécialiste de la région des grands lacs (lieux des "evenements" du film).
Elle a un peu relativiser la version noire du réalisateur (qui a d'ailleur préciser dans des interview qu'il voulait ne présenter que "le pire" de la vie locale).
En premier elle nous a mis des exemple ou les propos des intervenant n'etait qu'a "moitié traduits". (un exemple frappant est lorsque le PDG indiens est interrogé sur le nombre d'emploi induit par son industrie: il répond "10000 emploi direct et 150000 emplois indirects" sauf que la fin de la phrase n'est pas traduite, et on a la traduction du seul "1000 emplois directs")
Ensuite elle a analysé le film et la réalistion et a expliquer les nombreuses "mise en scene" ou "choix de réalisateur" qui apportaient beaucoup (trop?) dans la dramatisation des evenements.
Enfin elle a rappeler que cela n'etait pas scandaleux "historiquement". Les colonies ont toujours était pillées par les pays conquerant et s'offusquer maintenant d'un processus que l'on ne voulais pas voir/croire serait hypocrite. Cet "esclavagisme" a toujours existé et même si il faut le combatre, dire qu'on le découvre montre une certaine naivetée ou une certaine imbécilitée.
C'est ce que je trouve qui dessert le film, on sent le manque d'objectivité dans le fait qu'il veut "trop" en montrer. Même si tout est réel, le film est réalisé comme si il nous prenait par la main pour nous dire: "regarde la c'est pourri", "c'est pas biens", "regarde, la aussi" ... etc
Donc un excelent film/documentaire mais à relativiser un peu quand meme.
Complètement autre choses mais ca me tracasse depuis trop longtemps ...
Si tu pouvais m'expliquer l'interet d'avoir la documentation de VBasic, C++, C# ... sur la même page peut-etres que j'arriverrais a me calmer quand je recherche une foutue info dans la jungle qu'est MSDN.
(la question est vraiment sérieuse, je recherche vraiment la logique du truc)
...J'ai cédé aussi par envie d'humanisme, de me convaincre que le monde peu être beau, avec des gens qui demandent bien ... et de gens qui donnent aux gens qui le demandent bien, dans une vraie initiative constructive.
Aller avec moi !
Voici venu, le temps, des rires et des champs, dans l'ile aux enfants c'est tous les jours le printemps. C'est le pays, joyeux des enfants heureux ...
non je dirrait plutot ...
Kde c'est comme Java : super puissant mais développé par une boite qui fait du proprio
Gnome c'est comme mono : toujours a la traine et recopiant les trucs des concurant sans apporter d'innovation ...
>est écrit en C++
>il n'utilise pas d'exceptions,
>pas de méthodes virtuelles,
>extrêmement peu d'héritage
>évidemment pas la STL, (bon la OK ...)
>pas de templates, ...
La question logique qui en découle c'est : mais pourquoi ils utilisent le c++ ... pour faire "aware" ?
Il sous-entend qu'il faudrait rapprocher cette étude de celle-ci:
Une etude super-sérieuse a montré que l'immense majorité des tueurs en série aurrait regardé régulierrement la télévision avant de passer a l'acte ...
s/regardé * télévision/utilisé internet
s/regardé * télévision/écouté * musique
s/regardé * télévision/fait * pouet
Un peu gros mais bon hein ... je réagis "a chaud" au journal moi ...
Bin justement, la synchro, je ne l'ai jamais vue fonctionner parfaitement.
Le but effectivement c'est d'avoir une synchro parfaite intégré dans un editeur et qui permetrait de manipuler ton application "par le haut" avec les diagrames UML ou "par le bas" avec le code source.
Mais bon je n'ai pas encore rencontré l'outil miracle. Bien sûr il y a Eclipse mais pour Java seulement je crois.
Tu cite ADA sur .NET, mais je te signal qu'il y a également IronPython, qu'il y a également Eiffel (avec héritage multiple), mais aussi du Caml, etc. Pourtant ces langages respecte leur syntaxe et sémantique originale.
Bon ecoute, arrète de dire que c'est une avancé terrible d'avoir ces langages sur .Net.
-Pour Eiffel, l'implémentation est du pur hack de gros sagouin (bin faute de mieux quoi, fait tenir un langage avec heritage multiple, types ancrés et assertion sur une plateforme qui ne le supporte ...) ISE à juste réaliser cela pour faire un coup de pub pour son langage (Bertrand Meyer à fait des conférences pour Microsoft) mais aucun utilisateur du langage Eifel penserrais à utiliser mono (Eiffel et deja cross-plateforme).
-Pour Caml, ce lanage posséde déja un interpréteur, une VM, un compilo natif et pleins de bibliothèques, et le tout disponible pour plus d'architecture que .Net (ou mono) donc pouvoir le compiler sur .Net n'est absloument pas une avancé!
Pense que l'on pourrait réaliser un compilateur d'a peu prés n'importe quel langage pour qu'il produise du basic par exemple, oui cela n'aurrait aucun interet, un peu comme .Net qui supporte 50 langages différents.
il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori
Bon faut un peu arreter la, les 'binding' ne sont qu'un pis-aller. Ca se comprend trés biens pour des langages comme python mais un véritable langage (dont le but est une compilation native) aurra des plus qui nécessiteron de réécrire les bibliothèque pour utiliser ces + (en eiffel les agents par exemple)
OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?
Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?
et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)
Donc tu voudrais un seul framework et plusieurs langages qui l'utilise (tiens ca ressemble à .Net ...). Bon c'est que tu n'a riens compris aux differents apports des langages. Si mon langage possède l'héritage multiple, je _veux_ que le framework l'utilise, si mon langage possède les assertions, je _veux _ que mon framework l'utilise, si mon langage et fonctionel pur, je _veux_ que mon framework soit fonctionel pur, si mon langage et // ou distribué, je veux que mon framework en tienne comptes, sinon il n'y a _aucun_ interet à choisir tel ou tel langage (mis a part des notions discutables de syntaxe).
[mono tou ca ...] je peut utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli
Heu je fait une application en c# sur mono en utilisant gtk#, elle aurra le look&feel de kde si je l'utilise sous kde, de gnome sous gnome, de cocoa sous macOS, de windows sous windows? Non? ha bin GNUStep c'est pareil.
Par contre quand tu dit que tu t'intègre comme tu l'entend sans toucher au reste de ton applis, tu doit quand même recoder toutes la partie IHM non?
GNUStep propose un look&feel trés différent de ce qui existe actuellement sous Linux. Cela n'a riens à voir avec GNOME ni KDE. Ca se rapproche plutot de ce qui existe sous macOS.
Cette ergonomie à était trés "pensée" à la base, aprés c'est une question de gout. Donc effectivement une application GNUStep qui démarre sous KDE, sa fait aussi "tache" qu'une application GNOME.
Par contre le look&feel de GNUStep n'est _complet_ que si l'on utilise un windowmanager de type WindowMaker, en gros, GNUStep est alors dans son element.
je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé)
Je ne vois pas trop pourquoi ... par-ce-que sont ergonomie est trop differentes des poids lours que sont GNOME et KDE?
Ce n'est que depuis trés récemment que l'on peut avoir un bureau KDE ou GNOME trés unifié et sans une application qui fait tache au milieu car il n'existe pas d'equivalent sous G ou K.
Il y a quelques années, tout etait depareillé et on avait des applis gnome; kde, motif et TCL/TK en même temps.
Maintenant il est vrai que cela risque de "choquer" maintenant avec le niveau d'intégration que certains desktop on, mais normalement tu est sencé utilisé le desktop de GNUSTEP: GWorkspace.
Maintenant Mono :
On sait tous que tu trouve cette plateforme super-geniale, qu'elle roxe tout ca mais bon, qu'est-ce-que ca viens faire?
Pour l'instant un framework _complet_ existe pour étres utilisé avec obj-c, c'est GNUStep.
Le nombres d'autres framework ou bibliothèques (comme QT ou GTK) accessible directement via l'obj-c (par bibnding ou autres) est trés limité (surtout en IHM : je n'en vois pas d'autres!). Mais personne ne t'interdit de le faire.
Donc effectivement, vouloir ecrire une application qui s'intègre à KDE ou GNOME en obj-c, c'est moins evident, mais cela n'a rien a voir avec GNUStep.
Autres choses, et pour rentrer un peu plus dans ton troll, obj-c est un excellent langage pour réutiliser l'existant: interfacage direct avec le C, interfacage direct avec le C++ (bon OK, l'equipe de GCC à encore ca dans le TODO mais Apple le fait trés biens), et quelques possibilitées du langages qui n'existent pas ailleur (category, protocol). Ca c'est vnu langage proposant _vraiment_ quelques chose (pas comme c#).
Enfin, GNUStep n'est pas la pour enlarger ton p*, ni même faire croitre ton CA de 250% cette anné, ni même étres 'in' ou flashy branché, et encore moins d'etre sexy ou 'aware'.
Le but c'est d'implémenter des compcept qui, mêmes si ils ont été définis il y a lontemps, sont reconnus (Apple les utilisent!) et sont toujours d'actualité voir en avance même comparé avec d'autres plateforme soit-disant moderne comme mono ou java (en particulier les objets distribués)
Vous savez j'ai entendu une voix qui m'a dit qu'un gars hyper balaise (je crois que sont pseudo c'est "garbage_collector") faisait tout cela et même en mieux! Peut-etres qu'ont devrait lui proposer de travailler dans les logiciel libres non?
ps: Une autre voix m'a dit aussi que C++ c'etait le Cobol des années 90 (et mantenant 2000). Mais bon la c'est sûr, c'etait un troll ...
Un flux de donné, n'est pas un objet. Un flux est un flux ! ....
Non. Ce que tu apelle "flux" n'est qu'une modélisation d'un type de structure de donnée. En fait ce que tu apelle "flux" c'est (en gros) un 'struct' et des fonctions spécifiques à ce 'struct'. Tu peut trés biens modélisé un flux sous forme "Objet" et profiter ainsi de toutes les capacitées de modélisation de ce paradigmes (encapsulation, héritage ...).
Tout tes exemple sont biens modélisé orienté objet dans des bibliothèques orientés objet, c'est donc qu'il est possible de considérer une connexion comme un objet, une socket comme un objet, un fichier comme un objet ...
Avoir document.sauver() ou sauver(document) est du parail au même.
Bin non, une _enorme_ différences se trouve ici : cela s'appelle l'encapsulation et il à été prouvé que c'etait une tres bonne chose pour la réutilisation, toutca ....
Du coup si tu pense que "document.sauver() ou sauver(document)" c'est la même chose je te laisse à ton bad trip du reste de ton post car tu m'a l'air pas mal allumé pour un gars "qui s'y connait en objet". (ooooppppsss j'ai dérapé la ...)
ARGH !!!
Mais arretez! (je répond au 2 post du dessu)
Les principes objet ne peuvent pas etres décrit par leur implémentation. Quel mal à réalisé C++ et surtout Stroustrup en décrivant son langage par l'implémentation !
Les principes objets ne se résument absolument pas àde la manipulation de tableaux de pointeurs sur fonctions. Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Quand on parle de programmation objet en C c'est un _énorme_ abut de langage!
Dans le liens sur "oopc", rien que dans l'intro on apprend que le gars n'a rien compris au principes objet: OOPC does not provide
-Pointer to virtual member function handling polymorphism (too complex or slow)
Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
Je le repette: dire que l'on fait de la programation objet en C c'est comme dire que l'on fait de la programation fonctionelle pure en assembleur; vous voyez le problème quand même!
Un langage fonctionel pur ce n'est pas la même chose que le langage C.
Un langage permettant la concurrence n'est pas la même chose que le langage C.
Un langage de programmation logique n'est pas la même chose que le langage C.
Un langage objet n'est pas la même chose que le langage C.
Et pourtant tous ces langage peuvent etres implémenté en langage C! N'ont-ils pourtant aucun interet?
Les langages objets souffrait d'une mauvaise implémentation qui donnait des perfs biens moindres que dans des langages plus "bas niveau" comme le C.
Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
>On parle de la covaraince du type de retour
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
Ca n'a absolument pas le même but. La covariance permet une modélisation élégante et efficace.
Une bibliothèque n'est pas censé être modifiée ... tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment? Tu propose de définir une interface pour chaque exportation possible, je doit donc creer une interface spécifique (et qui ne servira à riens d'autres) pour chaque clause d'exportation? Tu trouve toujours cela "élégant"?
Au sujet des Aspect ...
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle; je ne trouve cela vraiment pas adapté. Le problème est juste d'avoir la possibilité d'ajouter une methode à une classe (en statique, la classe n'etant pas la tienne tu ne peut pas toucher le code). La possibilité de manipuler une classe et de lui ajouter une méthode est loins d'etre compliqué au point d'inventer des mecanismes super sofistiqués (et surtout qui rompent avec la conception objet).
[sous .Net] tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité (je ne me rapelle plus l'appelation) et du coup ceux qui font les API, ne peuvent pas reellement exploiter toutes les possibilitées du langage qu'ils utilisent si ils veulent etres "compliant".
Mois si j'utilise un langage foncitonel, c'est pas pour faire de l'objet. Si je fait une biliothèque en langage fonctionel, Ok, elle sera directement utilisable sous d'autres langages grace à .Net, mais elle ne sera pas homogène dans mon autres programe qui l'utilise écrit lui en C#.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
Non pas forcement, il y a toujours une autre solution.
Dur a suivre si on ne ce répond pas dans le même sens! ;-)
Non il n'y a pas d'autres solution que de dupliquer ton code. Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire! (non ce n'est pas moi qui suit mauvais, mais Ok cela reste -heureusement- peu fréquent)
Au sujet des mixins (du post du dessu) il est vrais qu'ils se propose d'étres une alternative à l'héritage multiple, mais je ne trouve pas leur utilisation reelement plus simple.
Au sujet du "Virtual" ...
Toujours les même arguments.
Sur la performance, c'est n'importe quoi: .Net est une machine virtuelle! donc ce n'est pas sur un petit appel de méthode que l'on va gagner les perf! Pour la version compilé (je sais que tu va m'en parler) des langages propose des methodes "tout" virtuel et une implémentation trés trés veloce! (biens meilleure que pour le C++ par exemple) donc l'argument ne tiens plus vraiment la route avec les progrés des compilo de nos jours.
Pour le versionning, c'est pareil, des langages proposent du tout virtuel sans avoir de scories dans les bibliothèques qu'ils proposent. Dans le pire des cas le mot "final" (ou son equivalent) existait pour les cas trop critique.
Bref rien de neuf, avoir gardé ce mot est vraiment une grande erreur.
[Java était innovant] Dommage que ce n'est pas le cas de cette version
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage (mais pas par rapport au autres Ok)
Mais surtout, Java abandonne l'aspect "langage trés simple" qu'il avait.
[Eiffel] facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!): Eiffel facilite la réutilisation des bibliothque à un point qu'aucun langage compilé à typage statique n'a atteint.
La possibilité de le compiler vers .Net n'est qu'une démarche commerciale: Eiffel est déja multiplateforme (OK seulement Win et Linux mais c'est déja pas mal), possède un héritage multiple, des types ancré, des assertions trés puissantes, ... alors je ne pense pas que cela soit pour réutiliser les bibliothèque de .Net qui ne proposent aucune des ces possibilitées.
La encore on voit a quel point l'utilité de .Net est limitée: Je vais vouloir réutiliser des bibliothèque de .Net dans mon programme Eiffel? Elles serons modélisé avec un héritage simple et n'utiliserons pas la puissance du langage de mon application cible.
Un gros avantage est de pouvoir rapidement utilisé ces bibliothèque, mais cela n'est pas une solution vraiment idéale que de jongler intelectuelement avec différentes conceptions.
>pas de généricité contrainte.
Tu peux expliquer ?
En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type, par exemple:
ENSEMBLE_ORDONNE<T : COMPARABLE>
Un ensemble ordonné ne peut contenir que des elements qui sont comparables entres-eux.
... la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence ...
On parle de la covaraince du type de retour (du resultat quoi) qui à l'avantage d'etres sûr du point de vue des types.
Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement
Non! Contre exemple : En C il n'y a riens pour faire de l'objet et il y a donc des limitations pour faire de l'objet, meme si on peut faire autrement.
Avoir la possibilité de la covariance est vraiment interressant (et ne coute vraiment rien au langage). Ne pas l'avoir inclu dans un langage recent est une erreur, surtout quand ce langage n'a pas vraiment pour but d'etres simple (cf la fin de ce post).
>pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I ...
Non ce n'est pas discutable. Il ne propose pas de visibilité flexible point. Ta proposition est un hack immonde qui rendrait incompréhensible n'importe quelle bibliothèque un peu volumineuse. De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
l'heritage multiple n'est pas indispensable
Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Comme pour tout tes autres arguments précédent: effectivement on peut éviter d'utiliser l'héritage multiple mais dans certains cas tu sera embeter de ne pas l'avoir et du coup tu contournera le problème en duplicant ton code.
Ce concept peut très bien envisager avec une méthode orientée aspect...
Laisse les Aspect ou ils sont! Ajouter les aspect c'est introduire un nouveau paradigme (trés criticable en plus) dans un langage qui ferrait biens mieux de se concentrer sur l'aspect objet. Par contre l'ajout d'une methode à une classe aurrait etait une vraie nouvauté interressante (pour la version dynamique, je suis d'accort avec toi: je ne vois pas encore l'utilité ...)
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Mais de toutes facon le problème n'est pas de te donner un exemple car voila maintenant pourquoi C# est nul:
Le C# est l'un des dernier langages industriels (qui se veut trés utilisables donc) sorti. Or il n'a apporté aucune amélioration ni innovation notoire. Pire même, il a repris des scories incompréhensible pour un langage objet du "21eme siecle" : en l'occurence, le mot clef "virtual". Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet. De plus, l'ajout de ce mot clef empeche de langage de se prétendre vraiment "simple", du coup pourquoi ne pas avoir ajouter d'autres possibilitées plus "évoluées" (héritage multiple, covariance, types ancrés ...)
Java lui etait innovant pour l'epoque (un langage industriel multi-plateforme, pouvant etres orienté web, suffisament efficace, avec un gc et possédant un framework unifié et trés complet): il se voulait simple et a expliqué comme ca tous les manques que l'on pouvait lui reproché (généricité, héritage multiple ...)
Java ajoute maintenant certaines fonctionalitées, c'est plutot biens mais il ne faut pas réver: esseyer de faire évoluer un langage qui se voulait simple vers un langage proposant toutes les fonctionalitées possibles ne peut pas conserver une bonne intégration. Mais bon c'est un moindre mal.
Donc voila pourquoi C# est minable comparé à Java: il n'apporte riens, ou plutot apporte n'importe-quoi.
!Par contre! La plateforme .Net est une vraie innovation: la possiblitée de mélanger différents langages sur une VM. Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance.
Ok ca permet de réutiliser des bibliothèque d'autres langages plus rapidement, mais l'intégration ne peut pas vraiment etres homogéne et si on choisi un langage possédant un framework complet, cela devient inutile.
Mais cela a au moins le mérite d'avoir était proposé.
J'ai deja utilis'e l'heritage multiple en C++ sans probleme particulier
Car on utilise l'héritage multiple en C++ de manière beaucoup moins intensive qu'en Eiffel: Et pour cause! il n'y a aucun moyen de résoudre les conflits. Mais le problème classique du "diamand" en C++ est insoluble.
(sans notion de type primitif)
Cette affirmation est trés disuctable car les types expansés on pour principale raison d'étres l'implémentation de ces types primitif. Disons plutot que les type primitifs sont trés biens intégré en Eiffel, pas comme dans d'autres langages.
et inspiré de Smalltalk
Alors la j'aimerais bien avoir un lien car Eiffel est :
-un langage dont toutes les implémentation propose sont des compilateurs
-un langage à typage statique
-un lanage à héritage multiple
-un langage ne proposant pas de meta-niveau ni d'introspection
-un langage ayant une syntaxe vraiment propre
Donc il est inspiré de trés loin non?
Au sujet de l'héritage non-conforme, il a était introduit en partie pour résoudre les problèmes lié à l'héritage multiple. L'ancien mécanisme pour gérer c'est problèmes, le mot clef "select" était loins d'etres parfait. Malheureusement cela n'est génial:
D'une part il ne résoud pas tous le problèmes (voir la mailling list de SmartEifel) mais en plus ca casse un ensemble de bibliothèque qui éxistait déja et surtout ce n'est pas une feature standardisé!
L'équipe de SmartEiffel implémente des concepts qui anticipent la future version de Eiffel (la version 3). Même si je comprend que les devs se font plaisirs et veulent avancer, le problème est que le langage Eiffel n'arrivera jamais à surmonter les péchers de jeunesse qu'il avait : pas de norme officielle, des implémentation toutes incompatibles les unes avec les autres, un ensemble de bibliothèques réduites (et pour cause! a chaque version il faut les revoir!) et du coup un nombre d'applications utilisables plutot léger.
Eiffel est un super langage et SmartEiffel un compilo plutot efficace mais je pense qu'ils aurrait plutot dut implémenter les réels manque du langage (suport de la concurence et du chargement dynamique de classe) plutot que d'anticiper une future norme qui n'arrivera pas avant des années!
[^] # Re: de l'impartialité ...
Posté par thecat . En réponse au journal Le Cauchemar de Darwin.... Évalué à 1.
Les termes "naivetée" et "imbécilitée" sont les miens mais il n'attaquaient personne (ou alors tout le monde et moi y compris).
En fait s'ettait plutot pour décrire l'ambiance de la conférence ou les questions commencaient a venir sur le "capitalisme c'est mal", "tous pourri", "c'etait mieux avant" :
Elle a juste rappelé que la colonisation et surtout l'exploitation des richesse des colonies par les pays riches, et dans le _seuls_ interets de c'est dernier, n'avait jamais était abandonné et avait toujours continué sous d'autres formes. (c'est le but même d'un colonie!)
Biens sur que c'est scandaleux et qu'il faut faire quelque chose mais dire que l'on "découvre" le pillage des pays africains c'est surtout prouver que l'on avait fermé les yeux jusqu'a présent.
(et que donc gueuler sur les dirigeant/le systeme c'est rejeter la faute sur un autre car _normalement_ le "systeme" dans un pays démocratique c'est le peuple mais bon c'est un autres débat).
En fait c'etait juste pour relativiser la "_direction_" de la revolte que l'on a apres la vision du film qui ne doit pas vraiment portée uniquement contre le systeme/les politiques/le capitalisme mais plutot contre chacun de nous et contre notre "aveuglement".
# de l'impartialité ...
Posté par thecat . En réponse au journal Le Cauchemar de Darwin.... Évalué à 8.
Elle a un peu relativiser la version noire du réalisateur (qui a d'ailleur préciser dans des interview qu'il voulait ne présenter que "le pire" de la vie locale).
En premier elle nous a mis des exemple ou les propos des intervenant n'etait qu'a "moitié traduits". (un exemple frappant est lorsque le PDG indiens est interrogé sur le nombre d'emploi induit par son industrie: il répond "10000 emploi direct et 150000 emplois indirects" sauf que la fin de la phrase n'est pas traduite, et on a la traduction du seul "1000 emplois directs")
Ensuite elle a analysé le film et la réalistion et a expliquer les nombreuses "mise en scene" ou "choix de réalisateur" qui apportaient beaucoup (trop?) dans la dramatisation des evenements.
Enfin elle a rappeler que cela n'etait pas scandaleux "historiquement". Les colonies ont toujours était pillées par les pays conquerant et s'offusquer maintenant d'un processus que l'on ne voulais pas voir/croire serait hypocrite. Cet "esclavagisme" a toujours existé et même si il faut le combatre, dire qu'on le découvre montre une certaine naivetée ou une certaine imbécilitée.
C'est ce que je trouve qui dessert le film, on sent le manque d'objectivité dans le fait qu'il veut "trop" en montrer. Même si tout est réel, le film est réalisé comme si il nous prenait par la main pour nous dire: "regarde la c'est pourri", "c'est pas biens", "regarde, la aussi" ... etc
Donc un excelent film/documentaire mais à relativiser un peu quand meme.
[^] # Re: Peur...
Posté par thecat . En réponse au journal Qt 4.0 en GPL sous Windows. Évalué à 2.
Si tu pouvais m'expliquer l'interet d'avoir la documentation de VBasic, C++, C# ... sur la même page peut-etres que j'arriverrais a me calmer quand je recherche une foutue info dans la jungle qu'est MSDN.
(la question est vraiment sérieuse, je recherche vraiment la logique du truc)
Merci d'avance.
[^] # Re: Quel est le problème ?
Posté par thecat . En réponse au journal Contre les poursuites des téléchargeurs. Évalué à 6.
Ok, mais j'ai dut mal a le justifier pour les excés de vitesse (je parle juste du 50 en ville et du 90 sur route que des _millions_ de gens dépassent)
[^] # Re: ah ah ah
Posté par thecat . En réponse au journal La sécurité de Linux est un "mythe" déclare Microsoft. Évalué à 1.
s/bug/feature ... j'ai bon ?
[^] # Re: Franchement .....
Posté par thecat . En réponse au journal Aranque, mais sans crimes, ni botanique .... Évalué à 3.
Aller avec moi !
Voici venu, le temps, des rires et des champs, dans l'ile aux enfants c'est tous les jours le printemps. C'est le pays, joyeux des enfants heureux ...
[^] # Re: Re : Optimiser son sommeil
Posté par thecat . En réponse au journal Optimiser son sommeil. Évalué à 6.
[^] # Re: bloat
Posté par thecat . En réponse au journal Des nouvelles de Gnome. Évalué à 1.
Kde c'est comme Java : super puissant mais développé par une boite qui fait du proprio
Gnome c'est comme mono : toujours a la traine et recopiant les trucs des concurant sans apporter d'innovation ...
... quelqu'un pour me suivre ?
[^] # Re: le fameux programmeur de Microsoft
Posté par thecat . En réponse au journal Itinéraires facon Microsoft.... Évalué à -2.
[^] # Re: Linspire m'inspire....
Posté par thecat . En réponse au journal Logiciel GPL par Linspire?. Évalué à 1.
Genre xine plante tu appelle Linspire pour demander qu'est-ce-que c'est que ce bordel ...
Aprés la qualité du support c'est autre chose, tu ne peut pas savoir avant, mais c'est vrai même dans les boites "propriétaires" ...
[^] # Re: Pour le C++
Posté par thecat . En réponse au journal GNU/Hurd c'est quoi au fait ?. Évalué à 4.
>il n'utilise pas d'exceptions,
>pas de méthodes virtuelles,
>extrêmement peu d'héritage
>évidemment pas la STL, (bon la OK ...)
>pas de templates, ...
La question logique qui en découle c'est : mais pourquoi ils utilisent le c++ ... pour faire "aware" ?
[^] # Re: Les tribus informatiques
Posté par thecat . En réponse au journal Le troll selon SVM Mac. Évalué à 4.
[^] # Re: News ?
Posté par thecat . En réponse au journal Pourquoi Java est dangereux ?. Évalué à 1.
En tout cas tu part au quart de tour toi ...
[^] # Re: ...
Posté par thecat . En réponse au journal Dans leur face !. Évalué à 7.
Une etude super-sérieuse a montré que l'immense majorité des tueurs en série aurrait regardé régulierrement la télévision avant de passer a l'acte ...
s/regardé * télévision/utilisé internet
s/regardé * télévision/écouté * musique
s/regardé * télévision/fait * pouet
Un peu gros mais bon hein ... je réagis "a chaud" au journal moi ...
[^] # Re: UML?
Posté par thecat . En réponse à la dépêche Objecteering/UML 5.3.0 est sorti sous Linux x86. Évalué à 2.
Le but effectivement c'est d'avoir une synchro parfaite intégré dans un editeur et qui permetrait de manipuler ton application "par le haut" avec les diagrames UML ou "par le bas" avec le code source.
Mais bon je n'ai pas encore rencontré l'outil miracle. Bien sûr il y a Eclipse mais pour Java seulement je crois.
[^] # Re: enlarge your penis
Posté par thecat . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 4.
Bon ecoute, arrète de dire que c'est une avancé terrible d'avoir ces langages sur .Net.
-Pour Eiffel, l'implémentation est du pur hack de gros sagouin (bin faute de mieux quoi, fait tenir un langage avec heritage multiple, types ancrés et assertion sur une plateforme qui ne le supporte ...) ISE à juste réaliser cela pour faire un coup de pub pour son langage (Bertrand Meyer à fait des conférences pour Microsoft) mais aucun utilisateur du langage Eifel penserrais à utiliser mono (Eiffel et deja cross-plateforme).
-Pour Caml, ce lanage posséde déja un interpréteur, une VM, un compilo natif et pleins de bibliothèques, et le tout disponible pour plus d'architecture que .Net (ou mono) donc pouvoir le compiler sur .Net n'est absloument pas une avancé!
Pense que l'on pourrait réaliser un compilateur d'a peu prés n'importe quel langage pour qu'il produise du basic par exemple, oui cela n'aurrait aucun interet, un peu comme .Net qui supporte 50 langages différents.
il suffit de prendre l'exemple de GTK qui a été conçu pour être "bindé" facilement et donc utilisable depuis ton langage favori
Bon faut un peu arreter la, les 'binding' ne sont qu'un pis-aller. Ca se comprend trés biens pour des langages comme python mais un véritable langage (dont le but est une compilation native) aurra des plus qui nécessiteron de réécrire les bibliothèque pour utiliser ces + (en eiffel les agents par exemple)
OpenStep se vente d'être portable mais ne t'encourage pas du tout à t'intégrer dans les autres environnements, tu ne trouves pas celà contradictoire ?
Heu non ... je ne croit pas à une ergonomie parfaite et unique. Mais j'aime cette de NeXT mais bon c'est vrai que les frameworks pourrait y travailler dessu (sous formes de fichier de conf peut-etres?). Mais quel framework propose cela?
et apprendre un nouveau framework complet c'est légèrement rédibitoire comme qui dirait. Le langage ca encore c'est surmontable (et parfois agréable)
Donc tu voudrais un seul framework et plusieurs langages qui l'utilise (tiens ca ressemble à .Net ...). Bon c'est que tu n'a riens compris aux differents apports des langages. Si mon langage possède l'héritage multiple, je _veux_ que le framework l'utilise, si mon langage possède les assertions, je _veux _ que mon framework l'utilise, si mon langage et fonctionel pur, je _veux_ que mon framework soit fonctionel pur, si mon langage et // ou distribué, je veux que mon framework en tienne comptes, sinon il n'y a _aucun_ interet à choisir tel ou tel langage (mis a part des notions discutables de syntaxe).
[mono tou ca ...] je peut utiliser le toolkit graphique et m'intégrer comme je l'entend dans les différents environnements sans toucher au reste de mon appli
Heu je fait une application en c# sur mono en utilisant gtk#, elle aurra le look&feel de kde si je l'utilise sous kde, de gnome sous gnome, de cocoa sous macOS, de windows sous windows? Non? ha bin GNUStep c'est pareil.
Par contre quand tu dit que tu t'intègre comme tu l'entend sans toucher au reste de ton applis, tu doit quand même recoder toutes la partie IHM non?
[^] # Re: enlarge your penis
Posté par thecat . En réponse à la dépêche 10 ans d'OpenStep. Évalué à 5.
Cette ergonomie à était trés "pensée" à la base, aprés c'est une question de gout. Donc effectivement une application GNUStep qui démarre sous KDE, sa fait aussi "tache" qu'une application GNOME.
Par contre le look&feel de GNUStep n'est _complet_ que si l'on utilise un windowmanager de type WindowMaker, en gros, GNUStep est alors dans son element.
je m'apercois juste que c'est normal que ce projet en soti toujours à ce stade (pas utilisé)
Je ne vois pas trop pourquoi ... par-ce-que sont ergonomie est trop differentes des poids lours que sont GNOME et KDE?
Ce n'est que depuis trés récemment que l'on peut avoir un bureau KDE ou GNOME trés unifié et sans une application qui fait tache au milieu car il n'existe pas d'equivalent sous G ou K.
Il y a quelques années, tout etait depareillé et on avait des applis gnome; kde, motif et TCL/TK en même temps.
Maintenant il est vrai que cela risque de "choquer" maintenant avec le niveau d'intégration que certains desktop on, mais normalement tu est sencé utilisé le desktop de GNUSTEP: GWorkspace.
Maintenant Mono :
On sait tous que tu trouve cette plateforme super-geniale, qu'elle roxe tout ca mais bon, qu'est-ce-que ca viens faire?
Pour l'instant un framework _complet_ existe pour étres utilisé avec obj-c, c'est GNUStep.
Le nombres d'autres framework ou bibliothèques (comme QT ou GTK) accessible directement via l'obj-c (par bibnding ou autres) est trés limité (surtout en IHM : je n'en vois pas d'autres!). Mais personne ne t'interdit de le faire.
Donc effectivement, vouloir ecrire une application qui s'intègre à KDE ou GNOME en obj-c, c'est moins evident, mais cela n'a rien a voir avec GNUStep.
Autres choses, et pour rentrer un peu plus dans ton troll, obj-c est un excellent langage pour réutiliser l'existant: interfacage direct avec le C, interfacage direct avec le C++ (bon OK, l'equipe de GCC à encore ca dans le TODO mais Apple le fait trés biens), et quelques possibilitées du langages qui n'existent pas ailleur (category, protocol). Ca c'est vnu langage proposant _vraiment_ quelques chose (pas comme c#).
Enfin, GNUStep n'est pas la pour enlarger ton p*, ni même faire croitre ton CA de 250% cette anné, ni même étres 'in' ou flashy branché, et encore moins d'etre sexy ou 'aware'.
Le but c'est d'implémenter des compcept qui, mêmes si ils ont été définis il y a lontemps, sont reconnus (Apple les utilisent!) et sont toujours d'actualité voir en avance même comparé avec d'autres plateforme soit-disant moderne comme mono ou java (en particulier les objets distribués)
[^] # Re: Attention quand même
Posté par thecat . En réponse à la dépêche La robustesse de nombreux navigateurs web mise en cause. Évalué à -4.
ps: Une autre voix m'a dit aussi que C++ c'etait le Cobol des années 90 (et mantenant 2000). Mais bon la c'est sûr, c'etait un troll ...
[^] # Re: Padding
Posté par thecat . En réponse au journal L'informatique en carton. Évalué à 3.
si, l'hydrogene ...
... mais les camions de livraisons risquent de ressembler à ca alors:
http://www.wordiq.com/definition/Image:Hindenburg.jpg(...)
(pour les explications : http://www.wordiq.com/definition/Hindenburg_disaster(...) )
[^] # Re: hmm
Posté par thecat . En réponse au journal j'ai un rêve .... Évalué à 1.
Non. Ce que tu apelle "flux" n'est qu'une modélisation d'un type de structure de donnée. En fait ce que tu apelle "flux" c'est (en gros) un 'struct' et des fonctions spécifiques à ce 'struct'. Tu peut trés biens modélisé un flux sous forme "Objet" et profiter ainsi de toutes les capacitées de modélisation de ce paradigmes (encapsulation, héritage ...).
Tout tes exemple sont biens modélisé orienté objet dans des bibliothèques orientés objet, c'est donc qu'il est possible de considérer une connexion comme un objet, une socket comme un objet, un fichier comme un objet ...
Avoir document.sauver() ou sauver(document) est du parail au même.
Bin non, une _enorme_ différences se trouve ici : cela s'appelle l'encapsulation et il à été prouvé que c'etait une tres bonne chose pour la réutilisation, toutca ....
Du coup si tu pense que "document.sauver() ou sauver(document)" c'est la même chose je te laisse à ton bad trip du reste de ton post car tu m'a l'air pas mal allumé pour un gars "qui s'y connait en objet". (ooooppppsss j'ai dérapé la ...)
[^] # Re: Je me pose une question
Posté par thecat . En réponse au journal j'ai un rêve .... Évalué à 4.
Mais arretez! (je répond au 2 post du dessu)
Les principes objet ne peuvent pas etres décrit par leur implémentation. Quel mal à réalisé C++ et surtout Stroustrup en décrivant son langage par l'implémentation !
Les principes objets ne se résument absolument pas àde la manipulation de tableaux de pointeurs sur fonctions. Et au contraire, les principes objet demandent une aide _enorme_ du langage.
Quand on parle de programmation objet en C c'est un _énorme_ abut de langage!
Dans le liens sur "oopc", rien que dans l'intro on apprend que le gars n'a rien compris au principes objet:
OOPC does not provide
-Pointer to virtual member function handling polymorphism (too complex or slow)
Ce que l'on appelle de la programmation objet en C n'est autre que de la programation modulaire (ou legerement plus).
Je le repette: dire que l'on fait de la programation objet en C c'est comme dire que l'on fait de la programation fonctionelle pure en assembleur; vous voyez le problème quand même!
Un langage fonctionel pur ce n'est pas la même chose que le langage C.
Un langage permettant la concurrence n'est pas la même chose que le langage C.
Un langage de programmation logique n'est pas la même chose que le langage C.
Un langage objet n'est pas la même chose que le langage C.
Et pourtant tous ces langage peuvent etres implémenté en langage C! N'ont-ils pourtant aucun interet?
Les langages objets souffrait d'une mauvaise implémentation qui donnait des perfs biens moindres que dans des langages plus "bas niveau" comme le C.
Or maintenant on à réalisé des compilos qui concurence grandement le C (Eiffel, OCaml entres autres). Donc révisez votre jugement sur "l'objet c'est lent".
Pour revenir sur l'idée d'un OS tout objet: oui ce serrait biens car par exemple cela permettrait de cacher la notion de mémoire à un soft et ca se serait une enorme avancée!
Un pas moins ambicieux (et non spécifiques aux objets) serait d'ajouter un module de "garbage collector" directement au noyaux. Ainsi le systeme est en charge des objets et chaque applis n'embarque plus son propre garbage collector (explicite ou automatique).
[^] # Re: révolutionnaire !
Posté par thecat . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 4.
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
Ca n'a absolument pas le même but. La covariance permet une modélisation élégante et efficace.
Une bibliothèque n'est pas censé être modifiée ... tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment? Tu propose de définir une interface pour chaque exportation possible, je doit donc creer une interface spécifique (et qui ne servira à riens d'autres) pour chaque clause d'exportation? Tu trouve toujours cela "élégant"?
Au sujet des Aspect ...
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle; je ne trouve cela vraiment pas adapté. Le problème est juste d'avoir la possibilité d'ajouter une methode à une classe (en statique, la classe n'etant pas la tienne tu ne peut pas toucher le code). La possibilité de manipuler une classe et de lui ajouter une méthode est loins d'etre compliqué au point d'inventer des mecanismes super sofistiqués (et surtout qui rompent avec la conception objet).
[sous .Net] tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité (je ne me rapelle plus l'appelation) et du coup ceux qui font les API, ne peuvent pas reellement exploiter toutes les possibilitées du langage qu'ils utilisent si ils veulent etres "compliant".
Mois si j'utilise un langage foncitonel, c'est pas pour faire de l'objet. Si je fait une biliothèque en langage fonctionel, Ok, elle sera directement utilisable sous d'autres langages grace à .Net, mais elle ne sera pas homogène dans mon autres programe qui l'utilise écrit lui en C#.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
Non pas forcement, il y a toujours une autre solution.
Dur a suivre si on ne ce répond pas dans le même sens! ;-)
Non il n'y a pas d'autres solution que de dupliquer ton code. Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire! (non ce n'est pas moi qui suit mauvais, mais Ok cela reste -heureusement- peu fréquent)
Au sujet des mixins (du post du dessu) il est vrais qu'ils se propose d'étres une alternative à l'héritage multiple, mais je ne trouve pas leur utilisation reelement plus simple.
Au sujet du "Virtual" ...
Toujours les même arguments.
Sur la performance, c'est n'importe quoi: .Net est une machine virtuelle! donc ce n'est pas sur un petit appel de méthode que l'on va gagner les perf! Pour la version compilé (je sais que tu va m'en parler) des langages propose des methodes "tout" virtuel et une implémentation trés trés veloce! (biens meilleure que pour le C++ par exemple) donc l'argument ne tiens plus vraiment la route avec les progrés des compilo de nos jours.
Pour le versionning, c'est pareil, des langages proposent du tout virtuel sans avoir de scories dans les bibliothèques qu'ils proposent. Dans le pire des cas le mot "final" (ou son equivalent) existait pour les cas trop critique.
Bref rien de neuf, avoir gardé ce mot est vraiment une grande erreur.
[Java était innovant] Dommage que ce n'est pas le cas de cette version
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage (mais pas par rapport au autres Ok)
Mais surtout, Java abandonne l'aspect "langage trés simple" qu'il avait.
[Eiffel] facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!): Eiffel facilite la réutilisation des bibliothque à un point qu'aucun langage compilé à typage statique n'a atteint.
La possibilité de le compiler vers .Net n'est qu'une démarche commerciale: Eiffel est déja multiplateforme (OK seulement Win et Linux mais c'est déja pas mal), possède un héritage multiple, des types ancré, des assertions trés puissantes, ... alors je ne pense pas que cela soit pour réutiliser les bibliothèque de .Net qui ne proposent aucune des ces possibilitées.
La encore on voit a quel point l'utilité de .Net est limitée: Je vais vouloir réutiliser des bibliothèque de .Net dans mon programme Eiffel? Elles serons modélisé avec un héritage simple et n'utiliserons pas la puissance du langage de mon application cible.
Un gros avantage est de pouvoir rapidement utilisé ces bibliothèque, mais cela n'est pas une solution vraiment idéale que de jongler intelectuelement avec différentes conceptions.
[^] # Re: révolutionnaire !
Posté par thecat . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 7.
>pas de généricité contrainte.
Tu peux expliquer ?
En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type, par exemple:
ENSEMBLE_ORDONNE<T : COMPARABLE>
Un ensemble ordonné ne peut contenir que des elements qui sont comparables entres-eux.
... la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence ...
On parle de la covaraince du type de retour (du resultat quoi) qui à l'avantage d'etres sûr du point de vue des types.
Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement
Non! Contre exemple : En C il n'y a riens pour faire de l'objet et il y a donc des limitations pour faire de l'objet, meme si on peut faire autrement.
Avoir la possibilité de la covariance est vraiment interressant (et ne coute vraiment rien au langage). Ne pas l'avoir inclu dans un langage recent est une erreur, surtout quand ce langage n'a pas vraiment pour but d'etres simple (cf la fin de ce post).
>pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I ...
Non ce n'est pas discutable. Il ne propose pas de visibilité flexible point. Ta proposition est un hack immonde qui rendrait incompréhensible n'importe quelle bibliothèque un peu volumineuse. De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
l'heritage multiple n'est pas indispensable
Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Comme pour tout tes autres arguments précédent: effectivement on peut éviter d'utiliser l'héritage multiple mais dans certains cas tu sera embeter de ne pas l'avoir et du coup tu contournera le problème en duplicant ton code.
Ce concept peut très bien envisager avec une méthode orientée aspect...
Laisse les Aspect ou ils sont! Ajouter les aspect c'est introduire un nouveau paradigme (trés criticable en plus) dans un langage qui ferrait biens mieux de se concentrer sur l'aspect objet. Par contre l'ajout d'une methode à une classe aurrait etait une vraie nouvauté interressante (pour la version dynamique, je suis d'accort avec toi: je ne vois pas encore l'utilité ...)
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Mais de toutes facon le problème n'est pas de te donner un exemple car voila maintenant pourquoi C# est nul:
Le C# est l'un des dernier langages industriels (qui se veut trés utilisables donc) sorti. Or il n'a apporté aucune amélioration ni innovation notoire. Pire même, il a repris des scories incompréhensible pour un langage objet du "21eme siecle" : en l'occurence, le mot clef "virtual". Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet. De plus, l'ajout de ce mot clef empeche de langage de se prétendre vraiment "simple", du coup pourquoi ne pas avoir ajouter d'autres possibilitées plus "évoluées" (héritage multiple, covariance, types ancrés ...)
Java lui etait innovant pour l'epoque (un langage industriel multi-plateforme, pouvant etres orienté web, suffisament efficace, avec un gc et possédant un framework unifié et trés complet): il se voulait simple et a expliqué comme ca tous les manques que l'on pouvait lui reproché (généricité, héritage multiple ...)
Java ajoute maintenant certaines fonctionalitées, c'est plutot biens mais il ne faut pas réver: esseyer de faire évoluer un langage qui se voulait simple vers un langage proposant toutes les fonctionalitées possibles ne peut pas conserver une bonne intégration. Mais bon c'est un moindre mal.
Donc voila pourquoi C# est minable comparé à Java: il n'apporte riens, ou plutot apporte n'importe-quoi.
!Par contre! La plateforme .Net est une vraie innovation: la possiblitée de mélanger différents langages sur une VM. Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance.
Ok ca permet de réutiliser des bibliothèque d'autres langages plus rapidement, mais l'intégration ne peut pas vraiment etres homogéne et si on choisi un langage possédant un framework complet, cela devient inutile.
Mais cela a au moins le mérite d'avoir était proposé.
[^] # Re: Quelques "coquilles"
Posté par thecat . En réponse à la dépêche Sortie de Hercule la version 2 du compilateur SmartEiffel. Évalué à 2.
Car on utilise l'héritage multiple en C++ de manière beaucoup moins intensive qu'en Eiffel: Et pour cause! il n'y a aucun moyen de résoudre les conflits. Mais le problème classique du "diamand" en C++ est insoluble.
Je suis curieux de savoir quels sont les problemes qui apparaissent en pratique
lit ce mesage et les suivants (mailling liste de SmartEiffel).
http://wwsympa.loria.fr/wwsympa/arc/smarteiffel/2004-09/msg00167.ht(...)
# Quelques "coquilles"
Posté par thecat . En réponse à la dépêche Sortie de Hercule la version 2 du compilateur SmartEiffel. Évalué à 9.
(sans notion de type primitif)
Cette affirmation est trés disuctable car les types expansés on pour principale raison d'étres l'implémentation de ces types primitif. Disons plutot que les type primitifs sont trés biens intégré en Eiffel, pas comme dans d'autres langages.
et inspiré de Smalltalk
Alors la j'aimerais bien avoir un lien car Eiffel est :
-un langage dont toutes les implémentation propose sont des compilateurs
-un langage à typage statique
-un lanage à héritage multiple
-un langage ne proposant pas de meta-niveau ni d'introspection
-un langage ayant une syntaxe vraiment propre
Donc il est inspiré de trés loin non?
Au sujet de l'héritage non-conforme, il a était introduit en partie pour résoudre les problèmes lié à l'héritage multiple. L'ancien mécanisme pour gérer c'est problèmes, le mot clef "select" était loins d'etres parfait. Malheureusement cela n'est génial:
D'une part il ne résoud pas tous le problèmes (voir la mailling list de SmartEifel) mais en plus ca casse un ensemble de bibliothèque qui éxistait déja et surtout ce n'est pas une feature standardisé!
L'équipe de SmartEiffel implémente des concepts qui anticipent la future version de Eiffel (la version 3). Même si je comprend que les devs se font plaisirs et veulent avancer, le problème est que le langage Eiffel n'arrivera jamais à surmonter les péchers de jeunesse qu'il avait : pas de norme officielle, des implémentation toutes incompatibles les unes avec les autres, un ensemble de bibliothèques réduites (et pour cause! a chaque version il faut les revoir!) et du coup un nombre d'applications utilisables plutot léger.
Eiffel est un super langage et SmartEiffel un compilo plutot efficace mais je pense qu'ils aurrait plutot dut implémenter les réels manque du langage (suport de la concurence et du chargement dynamique de classe) plutot que d'anticiper une future norme qui n'arrivera pas avant des années!