Pourquoi des langages gérés par la mémoire, tels que Java, Javascript et C #, ont-ils conservé le mot clé `new`?

Le newmot clé dans des langages tels que Java, Javascript et C # crée une nouvelle instance d'une classe.

Cette syntaxe semble avoir été héritée de C ++, où elle newest utilisée spécifiquement pour allouer une nouvelle instance d'une classe sur le tas et renvoyer un pointeur sur la nouvelle instance. En C ++, ce n'est pas le seul moyen de construire un objet. Vous pouvez également construire un objet sur la pile, sans utiliser new- et en fait, cette manière de construire des objets est beaucoup plus courante en C ++.

Alors, venant d’un fond C ++, le newmot clé dans des langages tels que Java, Javascript et C # me paraissait naturel et évident. Ensuite, j'ai commencé à apprendre Python, qui n'a pas le newmot clé. En Python, une instance est construite simplement en appelant le constructeur, comme suit:

f = Foo()

Au début, cela me paraissait un peu déroutant, jusqu'à ce que je réalise qu'il n'y avait aucune raison pour que Python en ait new, car tout est un objet, il n'est donc pas nécessaire de lever les ambiguïtés entre les différentes syntaxes de constructeur.

Mais ensuite, j'ai pensé: à quoi sert vraiment newJava? Pourquoi devrions-nous dire Object o = new Object();? Pourquoi pas juste Object o = Object();? En C ++, il est absolument nécessaire new, car nous devons distinguer entre l’allocation sur le tas et l’allocation sur la pile, mais en Java, tous les objets sont construits sur le tas, pourquoi même le newmot-clé? La même question pourrait être posée pour Javascript. En C #, que je connais beaucoup moins bien, je pense qu’il newpeut être utile de distinguer les types d’objet des types de valeur, mais je ne suis pas sûr.

Quoi qu'il en soit, il me semble que de nombreux langages ayant succédé à C ++ ont simplement "hérité" du newmot clé - sans en avoir réellement besoin. C'est presque comme un mot-clé vestigial . Nous ne semblons en avoir besoin pour aucune raison, et pourtant, il est là.

Question: Ai-je raison à ce sujet? Ou y a-t-il une raison impérieuse qui newdoit être dans des langages à gestion de mémoire inspirés du C ++ tels que Java, Javascript et C #, mais pas Python?

Vos observations sont correctes. C ++ est une bête compliquée, et le newmot clé a été utilisé pour faire la distinction entre quelque chose dont on aurait besoin deleteplus tard et quelque chose qui serait automatiquement récupéré. En Java et en C #, ils ont abandonné le deletemot - clé car le ramasse-miettes s'en charge pour vous.

Le problème est alors pourquoi ont-ils gardé le newmot clé? Sans parler aux auteurs de la langue, il est difficile de répondre. Mes meilleures suppositions sont énumérées ci-dessous:

• C'était sémantiquement correct. Si vous connaissez C ++, vous savez que le newmot - clé crée un objet sur le tas. Alors, pourquoi changer le comportement attendu?
• Il attire l'attention sur le fait que vous instanciez un objet plutôt que d'appeler une méthode. Avec les recommandations de style de code Microsoft, les noms de méthode commencent par des lettres majuscules afin d'éviter toute confusion.

Ruby se situe quelque part entre Python et Java / C # dans son utilisation de new. En gros, vous instanciez un objet comme celui-ci:

f = Foo.new()

Ce n'est pas un mot-clé, c'est une méthode statique pour la classe. Cela signifie que si vous voulez un singleton, vous pouvez remplacer l'implémentation par défaut de new()pour renvoyer la même instance à chaque fois. Ce n'est pas forcément recommandé, mais c'est possible.

En bref, vous avez raison. Le mot-clé new est superflu dans des langages tels que Java et C #. Voici quelques idées de Bruce Eckel, membre du comité standard C ++ dans les années 1990 et qui a publié des ouvrages sur Java: http://www.artima.com/weblogs/viewpost.jsp?thread=260578

il devait y avoir un moyen de distinguer les objets de tas des objets de pile. Pour résoudre ce problème, le nouveau mot-clé a été approprié à partir de Smalltalk. Pour créer un objet de pile, il vous suffit de le déclarer, comme dans Cat x; ou, avec arguments, Cat x ("mitaines") ;. Pour créer un objet de tas, vous utilisez new, comme dans new Cat; ou nouveau chat ("mitaines") ;. Compte tenu des contraintes, il s’agit d’une solution élégante et cohérente.

Entrez Java, après avoir décidé que tout ce qui est en C ++ est mal fait et trop complexe. L'ironie ici est que Java pourrait et a pris la décision de jeter l'allocation de pile (en ignorant explicitement la débâcle des primitives, que j'ai déjà abordée ailleurs). Et comme tous les objets sont alloués sur le tas, il n’est pas nécessaire de faire la distinction entre l’allocation de pile et celle de tas. Ils auraient facilement pu dire Cat x = Cat () ou Cat x = Cat ("mitaines"). Ou encore mieux, l'inférence de type incorporée pour éliminer la répétition (mais cela - et d'autres fonctionnalités comme les fermetures - aurait pris "trop ​​longtemps", nous sommes donc coincés avec la version médiocre de Java à la place; l'inférence de type a été discutée mais je vais en parler. cela ne se produira pas et ne le devrait pas, étant donné les problèmes liés à l’ajout de nouvelles fonctionnalités à Java).

Je peux penser à deux raisons:

• new distingue entre un objet et une primitive
• La newsyntaxe est un peu plus lisible (IMO)

Le premier est trivial. Je ne pense pas qu'il soit plus difficile de distinguer les deux. La seconde est un exemple du point de vue du PO, qui newest en quelque sorte redondant.

Il pourrait cependant y avoir des conflits d’espace de noms; considérer:

public class Foo {
   Foo() {
      // Constructor
   }
}

public class Bar {
   public static void main(String[] args) {
      Foo f = Foo();
   }

   public Foo Foo() {
      return Foo();
   }
}

Vous pourriez, sans trop étirer votre imagination, aboutir facilement à un appel infiniment récursif. Le compilateur devrait appliquer une erreur "Nom de la fonction identique à l'objet". Cela ne ferait vraiment pas de mal, mais il est beaucoup plus simple à utiliser new, ce qui Go to the object of the same name as this method and use the method that matches this signature.veut dire que Java est un langage très simple à analyser, et je suppose que cela aide dans ce domaine.

Java, pour sa part, a encore la dichotomie de C ++: tout n'est pas tout objet. Java possède des types intégrés (par exemple, charet int) qui ne doivent pas être alloués de manière dynamique.

Cela ne signifie pas pour autant que cela newsoit vraiment nécessaire en Java: l'ensemble des types qui n'ont pas besoin d'être alloués de manière dynamique est fixe et connu. Lorsque vous définissez un objet, le compilateur peut savoir (et sait en fait) s'il s'agit d'une valeur simple charou d'un objet qui doit être alloué de manière dynamique.

Je m'abstiendrai (encore une fois) de donner mon avis sur ce que cela signifie pour la qualité du design de Java (ou son absence, selon le cas).

En JavaScript, vous en avez besoin, car le constructeur ressemble à une fonction normale. Comment JS devrait-il savoir que vous souhaitez créer un nouvel objet sans le nouveau mot clé?

Fait intéressant, VB en a vraiment besoin - la distinction entre

Dim f As Foo

qui déclare une variable sans l'affecter, l'équivalent de Foo f;C #, et

Dim f As New Foo()

qui déclare la variable et assigne une nouvelle instance de la classe, l’équivalent de var f = new Foo();C en, est une distinction de fond. Dans les versions antérieures à .NET, vous pouviez même utiliser Dim f As Fooou Dim f As New Foo- car il n'y avait pas de surcharge sur les constructeurs.

J'aime beaucoup de réponses et je voudrais juste ajouter ceci:
Cela facilite la lecture du code.
Cette situation se produirait souvent, mais considérez que vous vouliez une méthode au nom d'un verbe qui partage le même nom qu'un nom. C # et les autres langues ont naturellement le mot objectréservé. Mais si ce n'était pas le cas, cela Foo = object()résulterait de l'appel de la méthode objet ou instancierait-il un nouvel objet. Espérons que la langue sans newmot - clé dispose de protections contre cette situation, mais en newautorisant l' exigence du mot - clé avant l'appel d'un constructeur, vous autorisez l'existence d'une méthode portant le même nom qu'un objet.

Il y a beaucoup de traces dans de nombreux langages de programmation. Parfois, c'est là pour des raisons de conception (C ++ a été conçu pour être aussi compatible que possible avec C), parfois, c'est juste là. Pour un exemple plus flagrant, considérons dans quelle mesure l’ switchinstruction C cassée se propageait.

Je ne connais pas assez bien le langage Javascript et le langage C # pour le dire, mais je ne vois aucune raison de le faire newen Java, si ce n’est le cas du C ++.

En C #, cela permet aux types visibles dans des contextes où ils pourraient sinon être masqués par un membre. Le vous permet d'avoir une propriété avec le même nom que son type. Considérer ce qui suit,

class Address { 
    public string Street { get; set; }
    public string City { get; set; }
    public string State { get; set; }
    public string Zip { get; set; }
}

class Person {
    public string Name { get; set; }
    public Address Address { get; set; }

    public void ChangeStreet(string newStreet) {
        Address = new Address { 
            Street = newStreet, 
            City = Address.City,
            State = Address.State,
            Zip = Address.Zip
        };
    }
}

Notez que l'utilisation de newpermet d'indiquer clairement que Addressle Addresstype n'est pas le Addressmembre. Cela permet à un membre d'avoir le même nom que son type. Sans cela, vous auriez besoin de préfixer le nom du type pour éviter la collision de noms, tel que CAddress. C'était très intentionnel, car Anders n'a jamais aimé la notation hongroise ou quelque chose de similaire et voulait que C # soit utilisable sans elle. Le fait que ce soit aussi familier était un double bonus.

Fait intéressant, avec l'avènement de la transmission parfaite, le non-placement newn'est plus du tout requis en C ++. Donc, sans doute, ce n'est plus nécessaire dans aucune des langues mentionnées.

Je ne suis pas sûr que les concepteurs de Java aient pensé à cela, mais lorsque vous considérez les objets comme des enregistrements récursifs , vous pouvez imaginer que Foo(123)cela ne retourne pas un objet, mais une fonction dont le point fixe est l'objet créé (c.-à-d. Une fonction qui renverrait l'objet s'il est donné en argument, l'objet en cours de construction). Et le but de newest de "faire le noeud" et de retourner ce point de repère. En d' autres termes , newferait l'objet « à être » au courant de son self.

Ce type d’approche pourrait aider à formaliser l’héritage, par exemple: vous pourriez étendre une fonction objet avec une autre fonction objet et enfin leur fournir des éléments communs selfen utilisant new:

cp = new (Colored("Blue") & Line(0, 0, 100, 100))

Ici, &combine deux fonctions-objets.

Dans ce cas, newpourrait être défini comme:

def new(objectFunction) {
    actualObject = objectFunction(actualObject)
    return actualObject
}

Autoriser 'nil'.

Parallèlement à l'allocation basée sur le tas, Java a adopté l'utilisation d'objets nil. Pas simplement comme un artefact, mais comme une fonctionnalité. Lorsque les objets peuvent avoir un état nul, vous devez alors séparer la déclaration de l'initialisation. D'où le nouveau mot clé.

En C ++ une ligne comme

Person me;

Appellerait instantanément le constructeur par défaut.

La raison pour laquelle Python n'en a pas besoin, c'est en raison de son système de types. Fondamentalement, quand vous voyez foo = bar()en Python, peu importe qu’il s’agisse d’ bar()une méthode invoquée, d’une classe instanciée ou d’un objet foncteur; en Python, il n'y a pas de différence fondamentale entre un foncteur et une fonction (car les méthodes sont des objets); et vous pourriez même affirmer qu'une classe en cours d'instanciation est un cas particulier de foncteur. Il n’ya donc aucune raison de créer une différence artificielle dans ce qui se passe (d’autant plus que la gestion de la mémoire est extrêmement cachée dans Python).

Dans un langage utilisant un système de typage différent ou dans lequel les méthodes et les classes ne sont pas des objets, il est possible que la différence conceptuelle entre créer un objet et appeler une fonction ou un foncteur soit plus forte . Ainsi, même si le compilateur / interprète n'a pas besoin du newmot clé, il est compréhensible qu'il puisse être géré dans des langages n'ayant pas dépassé toutes les limites de Python.

En réalité, en Java, il y a une différence lors de l'utilisation de Strings:

String myString = "myString";

est différent de

String myString = new String("myString");

En supposant que la chaîne "myString"n'ait jamais été utilisée auparavant, la première instruction crée un seul objet String dans le pool String (une zone spéciale du segment de mémoire), tandis que la seconde crée deux objets, l'un dans la zone de segment normal pour les objets et l'autre dans le pool String. . Il est assez évident que la deuxième déclaration est inutile dans ce scénario particulier, mais est autorisée par le langage.

Cela signifie que new garantit que l'objet est créé dans cette zone spéciale du tas, allouée pour l'instanciation normale d'un objet, mais il peut exister d'autres moyens d'instancier des objets sans lui. celui ci-dessus est un exemple et il reste de la place pour l'extensibilité.

En C #, il est important de faire la distinction entre les objets créés sur la pile et le tas. Nous créons fréquemment des objets sur la pile pour de meilleures performances. Vous voyez, lorsqu'un objet de la pile sort de son champ d'application, il disparaît immédiatement lorsque la pile se défait, comme une primitive. Il n’est pas nécessaire que le ramasse-miettes en garde la trace et le gestionnaire de mémoire n’a pas besoin de temps système supplémentaire pour allouer l’espace nécessaire sur le tas.