Discussion :

[hegros]

Tu ne réponds pas vraiment à la question... (ou bien j'ai rien compris à ce que tu as dit)

Il me semble déjà avoir répondu oui c'est pauvre c'est cible nux ou win c'est pauvre 2 choix seulement comme base d'os fondamental. Pour ce que tu ne comprends pas c'est simple, le niveau de portabilité, en prenant le parc réel de machine, est identique du point de vue du pro java ou du pro dotnet.

J'arrête ici sinon on va encore dire que c'est du troll, en plus linux vs windows, parce que si tu comptes pour portable un programme qui tourne sur 2 versions différentes à base linux effectivement il y a tellement de version comparé à une base windows.

[millie]

Il me semble déjà avoir répondu oui c'est pauvre c'est cible nux ou win c'est pauvre 2 choix seulement comme base d'os fondamental.

C'est quoi les autres OS auquels tu penses sur les stations et serveurs ?

[hegros]

C'est quoi les autres OS auquels tu penses sur les stations et serveurs ?

Vraiment vous insistez mais je ne vois pas où vous voulez en venir

[blbird]

Vraiment vous insistez mais je ne vois pas où vous voulez en venir

Je suis comme Millie, je te renvois ta remarque.

[millie]

Vraiment vous insistez mais je ne vois pas où vous voulez en venir

Si tu trouves que les dérivées d'UNIX et Windows sont pauvres comme "base d'os fondamental" pour le JDK de Java. Je cherche à comprendre quelles sont les OS auxquels tu penses afin que le choix soit moins pauvre.

D'où ma question :
- Quelles sont les OS pour lesquels il n'y a pas de JDK ? (toujours pour les stations et les serveurs) Ou autrement reformulé : Quels OS nécessiteraient un JDK pour que tu considères l'offre comme moins pauvre ?

[adiGuba]

Je reprend la discussion sur les properties et les évolutions du langage en général...

Si le prix d'une approche pas trop restrictive est un légère lourdeur consistant à laisser cohabiter les deux possibilités, est-ce vraiment si cher payé ?

Soit les properties génèreront des méthodes getter/setter "standard", et dans ce cas on se rapproche plus d'un sucre syntaxique.
Soit les properties sont bien distincte, et cela impliquerait de coder des getter/setter en plus pour utiliser ses classes avec des librairies externes non-compatible...

Je me doutais bien que certains problèmes devaient se situer au niveau reflexivité, mais ça ne me paraît pas insurmontable.

Je ne dis pas que c'est insurmontable !
Je dis simplement que cela risque d'apporter de nouveau problème, pour un gain qui n'est pas forcément extraordinaire.

Attention je ne dis pas que les properties sont inutiles (loin de là), mais simplement que ce n'est pas vraiment une fonctionnalité révolutionnaire...

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 méta-données.

Oui mais c'est intégré aux bases du langages depuis le début.
Je suppose que ces méthodes ne sont pas appelables directement dans le code, que tu ne peux pas les redéfinir ou les surcharger... (le tout sans passer par la syntaxe des properties bien sûr.


Bref il y a pas mal de petit détail "problématique", et comme le monde Java est plus "conservateur" cela tarde à venir (comme je l'ai dit sauf changement les properties ne devrait pas être intégré à Java 7).



C'est vraiment dans la philosophie de Java de bien mesurer les fonctionnalités à intégrer et des conséquences que cela peut avoir.

J'aime bien prendre l'exemple des Generics pour démontrer cela :

• Dans Java l'implémentation des Generics a été entièrement basé sur la compatibilité. Si bien qu'on peut très bien utiliser une classe Generics avec une librairie conçus pour les versions précédentes. Ainsi l'API de Collections a été mise à jour sans casser la compatibilité.
  Bien sûr cela a nécessiter quelques
• Dans C# l'implémentation des Generics a impliqué une incompatibilité : la nouvelle API System.Collections.Generic vient remplacer l'ancienne API System.Collections.
  C'est toutefois moins problématique vue la jeunesse du langage à l'époque.

a++

[davcha]

Oui mais c'est intégré aux bases du langages depuis le début.
Je suppose que ces méthodes ne sont pas appelables directement dans le code, que tu ne peux pas les redéfinir ou les surcharger... (le tout sans passer par la syntaxe des properties bien sûr.

En fait, en .NET, tu peux pas faire ça :

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
class Toto{
  int I{get{...}}
  int get_I(){...}
}

[FremyCompany]

Les propriétés ne sont ni plus ni moins des fonctions. Tu peux en effet laisser le compilateur les écrire pour toi si tu fais juste du backing field, mais tu peux les redéfinir sans difficulté.

C'est totalement prévu pour.

Code VB.NET :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Private Var1, Var2, Var3 as Boolean
 
''' <summary>
''' Get the state of System-X
''' </summary>
''' <value>The state of System-X</value>
Public ReadOnly Property P2() as Boolean
   Get
      Return ((Me.Var1 AndAlso Me.Var2) Or Me.Var3)
   End Get
End Property
 
''' <summary>
''' Set the user floag for the state of System-X
''' </summary>
Public WriteOnly Property P2() As Boolean
   Set(value as Boolean)
      If Me.Var1 Then Me.Var2 = Value
   End Set
End Property

[adiGuba]

mais tu peux les redéfinir sans difficulté.

Même dans une classe fille ???



Ce que je voulais dire surtout c'est que c'est bien gérer dans le langage : la redéfinition se fait sur la property.

En imaginant des property Java qui générerait des getter/setter (ce qui a été dit plus haut), on se retrouverait avec des cas bien moins clair...

a++

[davcha]

Code c# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
class Mother
{
	public virtual string Name { get; set; }
}
 
class Daughter : Mother
{
	public override string Name
	{
		get
		{
			return base.Name;
		}
		set
		{
			base.Name = value;
		}
	}
}

Pas de souci.

[adiGuba]

Je crois qu'on ne se comprend pas...

Je ne dis pas qu'il n'est pas possible de redéfinir les getter/setter des properties en .NET.

Ce que je voulais dire surtout c'est que c'est bien gérer dans le langage : la redéfinition se fait sur la property.

Au contraire je dis que cela fonctionne très bien en C# car c'est pensé pour dès l'origine du langage.



En Java c'est la notion de méthode getter/setter qui était présent à l'origine du langage, et on ne peut pas s'en passer aussi facilement. Du coup l'intégration d'un système de property posent problème car il doit être "compatible" ce qui lui fait perdre beaucoup de ses avantages...

a++

[_skip]

Sur ce problème de properties en java, ce qui me tue ce n'est pas le manque de la fonctionnalité en soi mais le code de documentation nécessaire.

En .Net

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
/// <summary>
/// Gets / Sets the 2 characters ISO 639-1 language code of the current user.
/// </summary>
public string LanguageCode
{
    get { return _languageCode; }
    set { _languageCode = value; }
}

En java :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
    /**
     * Gets the 2 characters ISO 639-1 language code of the current user.
     * @return the language code
     */
    public String getLanguageCode()
    {
        return this.languageCode;
    }

    /**
     * Sets the 2 characters ISO 639-1 language code of the current user.
     * @param languageCode the language code
     */
    public void  setLanguageCode(String languageCode)
    {
        this.languageCode = languageCode;
    }

C'est forcé si je veux que la génération de javadoc se passe correctement. Si je voulais ajouter des informations concernant la valeurs par défaut ou un seealso vers wikipedia pour la norme 639-1, je devrais le faire à 2 endroits.

C'est pas la mort mais sur des classes d'une vingtaine de propriétés, c'est chiant à la longue de documenter 2 méthodes plus respectivement le paramètre et la valeur de retour à chaque fois.

[Médinoc]

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:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    public String getLanguageCode()
    {
        return this.languageCode;
    }
 
    public void  setLanguageCode(String languageCode)
    {
        this.languageCode = languageCode;
    }
 
    /**
     * Gets / Sets the 2 characters ISO 639-1 language code of the current user.
     */
    public String LanguageCode
    {
        get = getLanguageCode;
        set = setLanguageCode;
    }
 
    /** Returns 42. */
    public int UneProprieteIntegree
    {
        get { return 42; }
    }

Ou alors:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
    /**
     * Gets / Sets the 2 characters ISO 639-1 language code of the current user.
     * @propertySetterName setLanguageCode
     * @propertyGetterName getLanguegeCode
     */
    public String LanguageCode
    {
        get = { return this.languageCode; }
        set { this.languageCode = value; }
    }
 
    /** Returns 42. */
    public int UneProprieteIntegree
    {
        get { return 42; }
    }

[_skip]

Ce ne serait pas ce qui se faisait dans les outils borland à un moment?

[Médinoc]

Ç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).

[robert_trudel]

C'est pas comme si j'avais parlé d'OS/400, HP-UX, Mac, z/OS, AIX, IRIX, BSD, Solaris.
Avec Windows et Linux (x86, ARM, powerpc, MIPS), ce qui correspond à 99% du marché stations et serveurs .

ms a porté .net sur tout ces os et cpu?

[sinok]

ms a porté .net sur tout ces os et cpu?

Non, millie parlait de java dans ce que tu cites.

[kedare]

Vous pensez que NET serais pas mal pour moi qui cherche un "framework universel" permettant d'utiliser un langage pour faire le plus de choses possibles (Web coté serveur, Applications desktop, "applets", etc), Ca a l'air de correspondre a ca... En plus même les linuxiens préfèrent les application Mono que java car elles sont mieux intégrés (avec GTK#)

[FONSI17]

On compare pas un lion a un chat bien évidement Java c'est le grand père de la plate forme .net

[robert_trudel]

En plus même les linuxiens préfèrent les application Mono que java car elles sont mieux intégrés (avec GTK#)

il y a des statistique là-dessus?