Por que linguagens gerenciadas por memória como Java, Javascript e C # mantiveram a palavra-chave `new`?

A newpalavra-chave em linguagens como Java, Javascript e C # cria uma nova instância de uma classe.

Essa sintaxe parece ter sido herdada do C ++, onde newé usada especificamente para alocar uma nova instância de uma classe na pilha e retornar um ponteiro para a nova instância. No C ++, essa não é a única maneira de construir um objeto. Você também pode construir um objeto na pilha, sem usar new- e, de fato, essa maneira de construir objetos é muito mais comum em C ++.

Portanto, vindo de um background em C ++, a newpalavra - chave em linguagens como Java, Javascript e C # parecia natural e óbvia para mim. Então comecei a aprender Python, que não tem a newpalavra - chave. No Python, uma instância é construída simplesmente chamando o construtor, como:

f = Foo()

No começo, isso me pareceu um pouco complicado, até que me ocorreu que não havia razão para o Python ter new, porque tudo é um objeto, então não há necessidade de desambiguar as várias sintaxes dos construtores.

Mas então eu pensei - qual é realmente o sentido disso newem Java? Por que deveríamos dizer Object o = new Object();? Por que não apenas Object o = Object();? No C ++, há definitivamente uma necessidade new, pois precisamos distinguir entre alocar na pilha e alocar na pilha, mas em Java todos os objetos são construídos na pilha, então por que ter a newpalavra - chave? A mesma pergunta pode ser feita para Javascript. Em C #, com o qual estou muito menos familiarizado, acho que newpode ter algum objetivo em termos de distinguir entre tipos de objeto e tipos de valor, mas não tenho certeza.

Independentemente disso, parece-me que muitas linguagens que vieram depois do C ++ simplesmente "herdaram" a newpalavra-chave - sem realmente precisar dela. É quase como uma palavra-chave vestigial . Parece que não precisamos dele por nenhum motivo, e ainda está lá.

Pergunta: Estou correto sobre isso? Ou existe algum motivo convincente que newprecisa estar em linguagens gerenciadas por memória inspiradas em C ++, como Java, Javascript e C #, mas não Python?

Suas observações estão corretas. C ++ é uma fera complicada, e a newpalavra - chave foi usada para distinguir entre algo que precisava deletemais tarde e algo que seria recuperado automaticamente. Em Java e C #, eles soltaram a deletepalavra - chave porque o coletor de lixo cuidaria dela por você.

O problema então é por que eles mantiveram a newpalavra - chave? Sem falar com as pessoas que escreveram o idioma, é meio difícil de responder. Meus melhores palpites estão listados abaixo:

• Era semanticamente correto. Se você estava familiarizado com o C ++, sabia que a newpalavra - chave cria um objeto no heap. Então, por que mudar o comportamento esperado?
• Chama a atenção o fato de que você está instanciando um objeto em vez de chamar um método. Com as recomendações de estilo de código da Microsoft, os nomes dos métodos começam com letras maiúsculas, para que haja confusão.

Ruby está em algum lugar entre Python e Java / C # em seu uso new. Basicamente, você instancia um objeto como este:

f = Foo.new()

Não é uma palavra-chave, é um método estático para a classe. O que isso significa é que, se você quiser um singleton, poderá substituir a implementação padrão new()para retornar sempre a mesma instância. Não é necessariamente recomendado, mas é possível.

Em suma, você está certo. A palavra-chave new é supérflua em linguagens como Java e C #. Aqui estão algumas idéias de Bruce Eckel, que era membro do C ++ Standard Comitee na década de 1990 e depois publicou livros sobre Java: http://www.artima.com/weblogs/viewpost.jsp?thread=260578

precisava haver alguma maneira de distinguir objetos de pilha de objetos de pilha. Para resolver esse problema, a nova palavra-chave foi apropriada do Smalltalk. Para criar um objeto de pilha, você simplesmente o declara, como no Cat x; ou, com argumentos, Cat x ("luvas") ;. Para criar um objeto de heap, use new, como no novo Cat; ou gato novo ("luvas"); Dadas as restrições, esta é uma solução elegante e consistente.

Digite Java, depois de decidir que tudo o que o C ++ é mal executado e excessivamente complexo. A ironia aqui é que o Java pode e tomou a decisão de jogar fora a alocação de pilha (ignorando claramente o desastre de primitivos, que eu já havia abordado em outro lugar). E como todos os objetos estão alocados no heap, não há necessidade de distinguir entre alocação de pilha e heap. Eles poderiam facilmente ter dito Cat x = Cat () ou Cat x = Cat ("luvas"). Ou melhor ainda, a inferência de tipo incorporada para eliminar a repetição (mas isso - e outros recursos como fechamentos - levaria "muito tempo", por isso estamos presos à versão medíocre do Java; a inferência de tipo foi discutida, mas vou há chances de que isso não aconteça, e não deveria, dados os problemas na adição de novos recursos ao Java).

Há duas razões pelas quais posso pensar:

• new distingue entre um objeto e um primitivo
• A newsintaxe é um pouco mais legível (IMO)

O primeiro é trivial. Não acho que seja mais difícil diferenciar os dois. O segundo é um exemplo do argumento do OP, que é meio que newredundante.

Porém, pode haver conflitos de namespace; considerar:

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

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

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

Você poderia, sem muito esforço da imaginação, facilmente terminar com uma ligação infinitamente recursiva. O compilador precisaria aplicar um erro "Nome da função igual ao objeto". Isso realmente não faria mal, mas é muito mais simples de usar new, o que afirma que Go to the object of the same name as this method and use the method that matches this signature.Java é uma linguagem muito simples de analisar, e suspeito que isso ajude nessa área.

Java, por exemplo, ainda tem a dicotomia de C ++: não muito tudo é um objeto. Java possui tipos internos (por exemplo, chare int) que não precisam ser alocados dinamicamente.

Isso não significa que isso newseja realmente necessário em Java - o conjunto de tipos que não precisam ser alocados dinamicamente é fixo e conhecido. Quando você define um objeto, o compilador pode saber (e, de fato, sabe) se é um valor simples que charou um objeto que precisa ser alocado dinamicamente.

Eu evitarei (mais uma vez) opinar sobre o que isso significa sobre a qualidade do design do Java (ou a falta dele, conforme o caso).

Em JavaScript, você precisa disso porque o construtor se parece com uma função normal; então, como o JS deve saber que deseja criar um novo objeto, se não fosse a nova palavra-chave?

Curiosamente, VB faz necessário - a distinção entre

Dim f As Foo

que declara uma variável sem atribuí-la, o equivalente Foo f;em C # e

Dim f As New Foo()

que declara a variável e atribui uma nova instância da classe, o equivalente var f = new Foo();em C #, é uma distinção substantiva. No pré-.NET VB, você poderia usar Dim f As Fooou Dim f As New Foo- porque não havia sobrecarga nos construtores.

Eu gosto de muitas respostas e gostaria de acrescentar isso:
facilita a leitura do código
Não que essa situação aconteça com frequência, mas considere que você queira um método no nome de um verbo que compartilhe o mesmo nome que um substantivo. C # e outro idioma naturalmente têm a palavra objectreservada. Mas, se não fosse, seria Foo = object()o resultado da chamada do método de objeto ou instanciaria um novo objeto. Esperemos que a linguagem sem a newpalavra-chave tenha proteções contra essa situação, mas ao ter o requisito da newpalavra - chave antes da chamada de um construtor, você permite a existência de um método com o mesmo nome que um objeto.

Há muitas coisas vestigiais em muitas linguagens de programação. Às vezes, existe por design (o C ++ foi projetado para ser o mais compatível possível com o C); às vezes, está lá. Para um exemplo mais flagrante, considere até que ponto a switchinstrução C quebrada se propagou.

Eu não sei Javascript e C # bem o suficiente para dizer, mas não vejo razão para isso newem Java, exceto pelo C ++.

Em C #, permite tipos visíveis em contextos onde, de outra forma, poderiam ser obscurecidos por um membro. O permite que você tenha uma propriedade com o mesmo nome que seu tipo. Considere o seguinte,

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
        };
    }
}

Observe que o uso de newpermite que fique claro que Addressesse Addresstipo não é o Addressmembro. Isso permite que um membro tenha o mesmo nome que seu tipo. Sem isso, você precisaria prefixar o nome do tipo para evitar a colisão de nomes, como CAddress. Isso foi muito intencional, pois Anders nunca gostou da notação húngara ou de algo semelhante e desejou que o C # fosse utilizável sem ela. O fato de também ser familiar era um bônus duplo.

Curiosamente, com o advento do encaminhamento perfeito, a não colocação newtambém não é necessária em C ++. Portanto, sem dúvida, não é mais necessário em nenhum dos idiomas mencionados.

Não tenho certeza se os designers de Java tinham isso em mente, mas quando você pensa em objetos como registros recursivos , você pode imaginar que Foo(123)não retorna um objeto, mas uma função cujo ponto de correção é o objeto que está sendo criado (ou seja, função que retornaria o objeto se for dado como argumento o objeto que está sendo construído). E o objetivo de newé "dar um nó" e retornar esse ponto fixo. Em outras palavras new, tornaria o "objeto a ser" ciente disso self.

Esse tipo de abordagem pode ajudar a formalizar a herança, por exemplo: você pode estender uma função de objeto com outra função de objeto e, finalmente, fornecer a eles comum selfusando new:

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

Aqui &combina duas funções de objeto.

Nesse caso, newpode ser definido como:

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

Permitir 'nulo'.

Juntamente com a alocação baseada em heap, o Java adotou o uso de objetos nulos. Não apenas como um artefato, mas como um recurso. Quando os objetos podem ter um estado nulo, é necessário separar a declaração da inicialização. Daí a nova palavra-chave.

Em C ++, uma linha como

Person me;

Chamaria instantaneamente o construtor padrão.

A razão pela qual o Python não precisa disso é por causa do seu sistema de tipos. Fundamentalmente, quando você vê foo = bar()no Python, não importa se bar()é um método que está sendo chamado, uma classe que está sendo instanciada ou um objeto functor; em Python, não há diferença fundamental entre um functor e uma função (porque métodos são objetos); e você pode até argumentar que uma classe sendo instanciada é um caso especial de um functor. Portanto, não há razão para criar uma diferença artificial no que está acontecendo (especialmente porque o gerenciamento de memória é extremamente oculto no Python).

Em uma linguagem com um sistema de digitação diferente, ou na qual métodos e classes não são objetos, existe a possibilidade de uma diferença conceitual mais forte entre criar um objeto e chamar uma função ou functor. Portanto, mesmo que o compilador / intérprete não precise da newpalavra-chave, é compreensível que ela seja mantida em linguagens que não quebraram todos os limites do Python.

Na verdade, em Java, há uma diferença ao usar Strings:

String myString = "myString";

é diferente de

String myString = new String("myString");

Supondo que a string "myString"nunca tenha sido usada antes, a primeira instrução cria um único objeto String no pool de String (uma área especial da pilha) enquanto a segunda instrução cria dois objetos, um na área de heap normal para objetos e outro no pool de String . É bastante óbvio que a segunda declaração é inútil nesse cenário específico, mas é permitida pelo idioma.

Isso significa que new garante que o objeto seja criado nessa área especial do heap, alocado para instanciação normal do objeto, mas pode haver outras maneiras de instanciar objetos sem ele; o exemplo acima é um exemplo e há espaço para extensibilidade.

Em C #, new é importante distinguir entre objetos criados na pilha versus a pilha. Criamos frequentemente objetos na pilha para melhor desempenho. Veja, quando um objeto na pilha fica fora do escopo, ele desaparece imediatamente quando a pilha se desfaz, exatamente como um primitivo. Não é necessário que o coletor de lixo o controle e não há sobrecarga extra do gerenciador de memória para alocar o espaço necessário no heap.