Quelles fonctionnalités de Scala ne peuvent pas être traduites en Java?

Le compilateur Scala comstack directement en code octet Java (ou .NET CIL). Certaines des fonctionnalités de Scala pourraient être redéfinies directement en Java (simples, par exemple, pour les compréhensions, les classes, la traduction de fonction anonyme / interne, etc.). Quelles sont les fonctionnalités qui ne peuvent pas être traduites de cette façon?

C’est probablement surtout d’intérêt académique. Plus utilement, quelles sont les principales caractéristiques ou idiomes de Scala que VOUS utilisez et qui ne peuvent pas être facilement représentés en Java?

Y en a-t-il un autre? Des choses qui peuvent être faites directement en Java et qui n’ont pas d’équivalent direct en Scala? Idiomes en Java qui ne traduisent pas?

    À mon avis, cette question passe à côté de la question en nous demandant de comparer les langues de la machine virtuelle Java en examinant leur code source généré.

    Scala comstack en bytecode équivalent à Java. C’est-à-dire que le bytecode aurait pu être généré par un code écrit en Java. En effet, vous pouvez même obtenir que scalac produise un formulaire intermédiaire qui ressemble beaucoup à Java.

    Toutes les fonctionnalités telles que les traits (via des redirecteurs statiques), les retours non locaux (via des exceptions), les valeurs paresseuses (via des références), etc. peuvent toutes être exprimées par un programme Java, bien que de manière peut-être la plus laide!

    Mais ce qui fait scala scala et non Java, c’est ce que scalac peut faire pour vous, avant que le bytecode ne soit généré . Ce que scalac a pour scalac , en tant que langage à typage statique, est la possibilité de vérifier l’exactitude d’un programme, y compris l’exactitude du type (en fonction de son système de types ) au moment de la compilation.

    La différence majeure entre Java et scala (car Java est également typé statiquement) réside donc dans le système de types de scala, capable d’exprimer des relations de programmation que le système de types de java-the-language ne peut pas . Par exemple:

     class Foo[M[_], A](m : M[A]) trait Bar[+A] 

    Ce concept , que M soit un paramètre de type qui a lui-même des parameters de type ou que Bar est covariant, n’existe pas en Java-land.

    Les traits sont une chose qui n’a pas d’équivalent. Les traits sont des interfaces avec du code en eux. Vous pouvez copier le code dans toutes les classes ayant un trait mélangé, mais ce n’est pas la même chose.

    Aussi, je crois que le système de type scala est plus complet. Bien qu’il finisse par mapper les types de machine virtuelle (dont l’effacement est en réalité effacé). Vous pouvez exprimer certaines choses dans le système de types Scala qui peuvent ne pas être possibles en Java (comme les variances).

    Je pense qu’il n’y a pas d’équivalent pour mélanger dynamicment certains traits. Dans Scala, vous pouvez append au moment de la création de nouveaux objects des traits mélangés.

    Par exemple, nous créons un chien qui a faim et soif et un chien qui a juste faim.

     val hungryThirstyDog = new Dog with Hungry with Thirsty val onlyHungryDog = new Dog with Hungry 

    Je ne connais pas un moyen équivalent de le faire en Java. En Java, l’inheritance est défini de manière statique.

    Les conversions implicites n’ont pas d’équivalent simple en Java.

    Une caractéristique de scala pour laquelle j’ai trouvé un bon usage est la réification de type par Manifestes . Comme la machine virtuelle Java supprime toutes les informations de type des génériques, scala vous permet de conserver ces informations dans des variables. C’est quelque chose que Java reflection AFAIK ne peut pas gérer, car il n’ya pas d’argument pour les types dans le bytecode.

    Le cas dont j’avais besoin était de faire correspondre un modèle sur un type de List . C’est-à-dire que j’avais un object VertexBuffer qui stockait des données sur le GPU, pouvant être construit à partir d’une liste de flottants ou d’entiers. Le code du manifeste ressemblait à peu près à ceci:

     class VertexBuffer[T](data:List[T])(implicit m:Manifest[T]) { m.toSsortingng.match { case "float" => ... case "int" => ... } } 

    Ce lien renvoie à un article de blog contenant plus d’informations.

    Il y a beaucoup de pages SO avec plus d’informations, comme celle-ci .

    Trois mots: types plus gentils.

    Votre sujet n’est pas clair, vous voulez dire Java la JVM ou Java le langage. Étant donné que Scala fonctionne sur la machine virtuelle, le q n’a aucun sens, car nous soaps tous que Scala fonctionne sur la machine virtuelle.

    Scala a un support “natif” pour XML. Vous pouvez construire le XML, rechercher des éléments, faire correspondre directement dans le code Scala.

    Exemples: http://programming-scala.labs.oreilly.com/ch10.html