Os modificadores public e static poderiam ser implícitos.
Abraços.[/quote]
Do meu ponto de vista neste caso não poderiam, pois sem eles descritos de forma explicita não seria possível o compilador entender que o metodo “main” em questão se trataria do metodo principal, mesmo que o compilador levasse em consideração o nome do metodo e sua assinatura. Embora veja como incorreto a pessoa poderia ter uma classe que não fosse a principal e mesmo assim pretender colocar um metodo com o nome de “main”, e possuindo um “array” de “String” como parametro, e o programador não quer que seja o principal chamado pela aplicação. [/quote]
E se isso for uma especificação? Ai segue-se regras.[/quote]
Sim creio eu que seja uma especificação, porém neste caso em particular o metodo “main” e aberto a possibilidade do programdor decidir se o mesmo sera utilizado como principal por sua aplicação ou será apenas um metodo com o nome “main” sem ser o principal.
Porem em certos pontos a linguagem adota trechos implicitos, isso ao meu ver porque não poderia ser implementado de forma diferente, logo seria retundante informar o que so pode ser aquilo mesmo, um exemplo e uma “suposta” varíavel de instância em uma interface, sendo que a mesma se trata de uma constante, já que uma interface não pode conter varíaveis de instância.
Sendo assim pressumo que a Sun, adorte somente trechos implicitos quando o mesmo não possuir meios diferentes de ser declado.
Eu também acho que o método main está bom do jeito que está.
E também concordo com o Thigol, o método main do C e do C++ são realmente estranhos de se entender, muito piores que os do Java. Sou programador C++ a 10 anos.
E no java, vale mesmo o que está escrito. As regras de omissão costumam a ser bastante claras. Por exemplo, no caso de interfaces, a regra imposta é que todos os métodos são publicos, então, permite-se a omissão.
No caso do main, a JVM também permite que você tenha outros métodos, que não o principal, chamados main. Não creio que isso seja elegante, mas é possível e certamente alguém por aí reclamaria se a regra fosse alterada. Basta não declarado como static ou public.
Mas eu concordo com você em um aspecto. Poderiam ter criado uma sintaxe mais simples para o main, lá no começo do Java. Pena q agora talvez seja um pouco tarde…
PS: Thingol, essa história de pedir para o cara baixar os fontes me cheirou ao argumento do pessoal do Linux. Acho que a maior parte dos mortais evitará ao máximo baixar o código de um compilador ou de um SO se puder. Além disso, creio que nosso colega quisesse algo padrão, que servisse para comunidade, e não só para o compilador dele. Até pq, do contrário, ele nem precisa alterar o java.exe. Bastaria ele fazer um script que fizesse a leitura do arquivo com o main e o alterasse para a sintaxe normal, antes de compilar… (tal como várias mágicas sintáticas feitas pelo compilador do C ou do C++ antes de efetivamente compilar o código)
Claro, de qualquer forma, deve ser bastante interessante alterar o java.exe, como uma experiência…
Bom, de qualquer maneira, a última referência é a JLS - Java Language Specification.
Você pode sugerir alterações à linguagem úteis ou não tão úteis; bugs.sun.com recebe suas sugestões, assim como os fóruns de java.net.
[quote=ViniGodoy]
PS: Thingol, essa história de pedir para o cara baixar os fontes me cheirou ao argumento do pessoal do Linux. Acho que a maior parte dos mortais evitará ao máximo baixar o código de um compilador ou de um SO se puder. Além disso, creio que nosso colega quisesse algo padrão, que servisse para comunidade, e não só para o compilador dele. Até pq, do contrário, ele nem precisa alterar o java.exe. Bastaria ele fazer um script que fizesse a leitura do arquivo com o main e o alterasse para a sintaxe normal, antes de compilar… (tal como várias mágicas sintáticas feitas pelo compilador do C ou do C++ antes de efetivamente compilar o código)
Claro, de qualquer forma, deve ser bastante interessante alterar o java.exe, como uma experiência… ;)[/quote]
O pessoal de Java e o pessoal de Linux (e o de Open-Source, ou FOSS) têm muitos pontos em comum, incluindo alguma “religiosidade” e fanatismo que pode ser encontrado em ambos. (Sou velho demais para acreditar nessas coisas - declaro-me agnóstico). Você não percebeu?
De qualquer maneira, existem os canais adequados para a solicitação de novos recursos (bugs.sun.com, JCP, java.net etc.), e é possível fazer as experiências.
Que tal acrescentar “operator overloading” ao Java, por exemplo? Eu sei que em Java “vale o que está escrito” (se bem que o “foreach” não é bem assim…), e com “operator overloading” isso começará a não valer mais, mas isso pode ser tentado como uma experiência.
Ótimo, poderíamos adotar a sugestão dos mains parecidos com os do C++, acrescentar recursos de templates, constness, operator overloading, aritmética de ponteiros, suporte a funções estruturadas e sem classes e uma fase de substituição sintática (com macros e defines) e chamar a nova linguagem de Java++.
XML e SQL dentro do código já não são mascarados com anotações?[/quote]
Não é bem isso. É algo parecido com o LINQ, que vai aparecer no Visual Studio 2008.
Por exemplo, você pode fazer parse de XML com o LINQ em C# e VB.NET sem ter de usar DOM ou SAX ou coisa parecida - simplesmente especifique um fragmento do XML que você quer ler, com as variáveis onde os valores devem ser carregados.
[quote=ViniGodoy]Ótimo, poderíamos adotar a sugestão dos mains parecidos com os do C++, acrescentar recursos de templates, constness, operator overloading, aritmética de ponteiros, suporte a funções estruturadas e sem classes e uma fase de substituição sintática (com macros e defines) e chamar a nova linguagem de Java++.
