Bom, depois de amanha faço uma palestra sobre grails para os grupos de estudo das faculdades aqui de perto.
E montando esta palestra, lembrei de algumas coisas que são espetaculares no Groovy, e que o Grails acaba herdando, que fazem bastante falta no Java …
Segue uma pequena lista, se alguem lembrar de mais alguma cosa eu agradeço
- Sintaxe para declaração do valor de uma lista:
minhaLista = [1, 2, 3, 6, 50, 2000]
- Sintaxe para declaração do valor de umMap:
meuMap = ["rodrigo":"urubatan", "numero":300]
- Acesso a objetos dos mapas similar a EL embutido na linguagem:
meuMap.rodrigo meuMap["rodrigo"]
- == é a mesma coisa que equals, isto evita problemas por falta de atenção
- this dentro de um método estático referencia a classe (como eu mencionei aqui)
- Facilidade para evitar NullPointerException:
para acessar um método de uma variável que pode ser nula sem precisar escrever um if, é só usar:variaval?.metodo()
o método só vai ser chamado se a variável não for null.
- Closures (referencia mais completa do que 1 linha aqui)
- Expressões regulares nativas (semelhante ao Javascript).
- a chave para o “switch” em groovy pode ser uma string, quer dizer, na verdade ela pode ser qualquer coisa praticamente
- Possibilidade de utilização de variáveis dentro de strings (se estas estiverem demarcadas com aspas duplas, o groovy suporta aspas simples e duplas para strings), e Strings multi linha (utilizando a barra invertida):
def texto = "Bom dia ${nome} strings multi linha são legais"
Bom, acho que era isto, estas não são todas as diferenças entre Groovy e Java, mas são as que estão fazendo diferença para mim

Concordo, com execeção de dois itens: não é bom == ser a mesma coisa que equals pois qualquer linguagem orientada a objetos faz distinção entre igualdade e semelhança. O problema é quando são os objetos que fazem ponte para uma base de dados relacional, pois bases de dados relacionais não fazem essa distinção. A meu ver é problema do mapeamento objeto-relacional e não da linguagem OO. O segundo item que não é bom é o switch mais fácil. Switch é erva-daninha na programação OO, pois 99% dos switchs podem ser substituídos com polimorfismo, dando maior clareza de código. Portanto, quanto mais difícil de se construir essa estrutura, melhor.
Quanto aos outros 8 itens, já deveriam estar no Java ontem.
‘==’ equivale ao equals()
‘===’ equivale ao ‘==’ do Java
Ei Urubatan, não existe “aspas duplas” e sim, aspas e apóstrofo.
Desculpa eu pegar no seu pé mas é que vejo muitos falando errado.
Flávio
Que horror! Tem gente dizendo que switch é uma erva daninha porque pode ser substituído por polimorfismo.
Quanta bobagem. Faz um interpretador de parâmetros de linha de comando com polimorfismo então!!
Eu poderia dizer que switch pode ser substituído por uma hash table (dictionary, map, o que for). Isso seria mais sensato. Mas mesmo assim, não há porque abolir o switch.
Na minha opinião, uma linguagem que não tem os itens 1, 2 (literais de arrays e maps) e 9 (switch de strings) e foi criada nos anos 90, é uma falha grande. Esses itens são básicos!!!! Tá certo que muitas linguagens clássicas não tinham isso. Mas o que passou, passou. A esta altura (anos 90 pra cá) criar uma linguagem de alto nível sem isso é burrice. Os outros também são bem convenientes e não trariam problemas, mas se uma linguagem resolve não incluir, não acho tão grave.
Pra mim, exemplos de design de linguagens são: Lua, Python, D e assemelhados
Anti-exemplos: Pascal, C, Java. As duas primeiras têm a desculpa da idade (mas Pascal é bem pior que C). Java não.
Meio-termo: C++ e outras que eu não lembro agora. :-p
Só por curiosidade, você já brincou com Jython?
ja sim, o problema é que o jython morreu a algum tempo
utilizei para calculos em um projeto a bastante tempo
iuyrisu wrote:
“Que horror! Tem gente dizendo que switch é uma erva daninha porque pode ser substituído por polimorfismo.
Quanta bobagem. Faz um interpretador de parâmetros de linha de comando com polimorfismo então!!”
Eu não acho que o switch devesse ser abolido, mas tento minimizar seu uso.
Para casos mais simples, onde existem poucos valores possíveis, eu uso as enumerações de Java 5. Quando faz sentido, eu faço uso do fato que enums são classes, e coloco o comportamento particular relacionado a cada valor da enum como métodos específicos ao valor na própria enum (que declara o método como abstract, ou com o comportamento default).
“Eu poderia dizer que switch pode ser substituído por uma hash table (dictionary, map, o que for). Isso seria mais sensato.”
Essa é uma alternativa.
Eu prefiro evitar a hash map e fazer um uso trivial de reflexão. No caso do interpretador, cria uma classe (subclasse de “Comando” para cada comando suportado. Cria uma convenção para mapear um nome de comando para um nome de classe (ou de método em uma classe). Ao processar um comando, tenta carregar a classe (ou encontrar o método) que corresponda ao comando. Se não existir, “Comando não conhecido”. Se existir, executa o comando.
Vantagem: a informação sobre um comando está apenas em um único lugar. Para se saber quais comandos existem, é só colocar todas as classes de comando em um pacote à parte, exemplo: “com.acme.interpretador.comandos” (ou abrir a classe que define os comandos como métodos). Para adicionar um novo comando, é só acrescentar uma classe (ou método). Para remover um comando, basta remover a classe (ou método).
Eu já usei essa estratégia muitas vezes. Prefiro muitas classes pequenas a métodos grandes e repetitivos (YMMV).
Apenas uma réplica com relação ao que iuyrisu respondeu: Eu não disse que switch pode ser substituído com polimorfismo, eu disse que 99% dos switchs podem ser substituídos por poliformismo. É claro! Existem exceções! E uma delas é a conversão de string para um comando na forma de chamada de método a um objeto. Ainda assim, dependendo do caso, consegue-se usar reflexão, no caso de Java. Outras linguagens possuem alguns recursos de lambda ou ligação tardia que também seriam úteis. Para casos mais gerais não vejo o porquê de alguém usar switch.
O que muitas vezes ocorre, é alguém fazer um switch onde cada bloco case possui umas 30 linhas ou mais. Isso é condenável. Se tiver que fazer switch, no máximo 2 ou 3 linhas para cada case. Não consigo imaginar um switch sendo substituído por hash e que seja melhor que polimorfismo, força a criação de flags para serem as chaves, cuja manutenção é complicada; com polimorfismo, a definição de qual método a ser chamado é automática.
3.step(9,3) {
println it
}
10.times {
println it
}
[1, 2, 3, 6, 50, 2000].each{
println it
}
my_string[1..
em vez de my_string[1..
queria dizer my_string[1..
Ao iuyrisu: duas das linguagens que você citou como boas caem no seu critério de falha grave: Lua e Python não tem switch
Walter, neste caso (pelo menos do python) que tem listas e closures (mesmo chamando com outro nome) acho que o switch seria até melhor substituido com um mapa e algumas closures
Sim, a solução idiomática do python é o dicionário (mapa)
(não ficou explícito, mas eu gosto de ambas, python e lua)
[...] o jar, e editarmos o arquivo templates/JpaEntity.gtl (imagino que a extensão GTL signifique Groovy Template [...]
[...] Java não tem nenhum destes recursos, mas faz algum tempo que ja temos muito mais do que isto com o Groovy por exemplo, e agora no JRuby para a [...]