Recherche:

Tu oublies que C# résout certains problèmes inhérents à Java (comme le manque de types valeur non-primitifs, la nécessité de passer par une allocation sur le tas pour pouvoir retourner plus d'une...

En plus, .Net a les deux: Namespaces et Assemblys.

Ce que j'appelle la "vraie" sérialisation de .Net, c'est le système utilisant:

L'attribut Serializable
Optionnellement, l'interface ISerializable et les types qui vont avec (SerializationInfo,...

Ce n'est pas ce que Nathanael Marchand voulait dire: Son post expliquait que dans le cas de la sérialisation XML comme celle utilisée pour les web services, seuls les membres publics (champs ou...

La sérialisation XML passe uniquement par les champs publics modifiables en .Net.

Avec la vraie sérialisation, tu peux faire ce que tu veux (mais il faut implémenter l'interface ISerializable et...

La même chose est faite par le debugger, d'ailleurs: Les propriétés sont évaluées, les getters non.

Ce qui en fait un avantage des propriétés sur les getters/setters: Choix contre absence de choix.

L'initialisation ne marche que sur les publics, bien sûr.

Et le problème du "Ouin il faut utiliser que les constructeurs" est tout aussi présent en Java.

En C# 3.0, tu peux initialiser avec les appels de propriétés:

MaClasse obj = new MaClasse() { Prop=toto, Prop2=tata };

^Du temps où j'étais couvert par MSDNAA, l'utilisateur avait le droit de garder Visual (mais n'était plus censé bénéficier de mises à jour).

Je pense qu'il a été plus ou moins établi que Java était très bien pour tout ce qui est Web.

Par contre, pour les applications Desktop, c'est .Net qui domine.

Ça y ressemblait en effet, mais je ne sais plus si c'était compatible avec les propriétés COM (elles-mêmes compatibles avec .Net).

Pour la compatibilité, je verrais bien des propriétés dont on peut overrider le nom par défaut des accesseurs. Un moyen serait un truc comme ça:

public String getLanguageCode()
{
...

C'est vrai qu'en .Net, on ne peut apparemment rien décharger de plus petit qu'un AppDomain, ce qui équivaut pratiquement à décharger tout le process...

Si tu regardes un assembly .Net avec ILDASM, tu verras que côté .Net, c'est le cas: Deux méthodes, et la "property" vient se greffer dessus comme du sucre syntaxique, mais qui passe dans les...

Passage par référence, ou comment retourner deux valeurs d'une même fonction sans passer par une coûteuse allocation dynamique.
Types Valeur non-primitifs.
Types génériques pris en charge par le...

Ça, c'est faux. Le plus vieux a un avantage sur le plus récent qui évite qu'il soit détrôné même si le plus récent est mieux (ce que je ne tenterai pas de confirmer ou infirmer dans ce message). Il...

En effet. Le multiplateforme est selon moi la plus grande faiblesse de .Net, et pour moi ce qui va le plus empêcher les programmeurs de profiter de la supériorité technique du CLR sur la JVM.

Un...

À ma connaissance, Java ne permet pas de créer ses propres types valeur, uniquement des types référence nécessitant une allocation (les seuls types valeur que connait Java sont les types primitifs)....

Je ne sais pas si c'est en totalité, mais c'est bien possible...

Office 2007 est bel et bien en .Net, ses DLLs COM sont devenus des assemblys COM-Visible.

@FremyCompany: En effet, mais généralement quand une application est pilotable par des classes .Net, ces classes sont aussi COM-exposables.

.Net et COM.
Tout ce qui peut être piloté depuis .Net peut l'être depuis COM, et vice versa.

Le compilo C# n'est pas dans Visual Studio, il est livré avec le Framework lui-même.
Pour le C#, Visual Studio est juste un EDI.

Tu sais, pendant des années ça a été Sun qui dirigeait Java, je ne sais pas si c'était forcément mieux...