Seja bem vindo ao Fórum do JavaFree.org
Aqui você irá encontrar respostas para TUDO o que você precisa sobre java.
Deseja participar? Crie sua conta ou efetue seu login
Uma discussão interessante sobre mudanças na linguagem Java apareceu no JavaLobby esses dias. O autor argumenta que faltam algumas construções que tornaria Java melhor e fala sobre como deveriam ter entrado já no Tiger. Como alterações na linguagem não foram planejadas para o Mustang, se alguma dessas mudanças vier, só as veremos bem mais no futuro. Os novos recursos e porque o autor acha que eles devam ser incorporados logo abaixo:
-Non null modifier for method parameters Method parameter validation is an important thing, that's what we've all learned. But as we all also know that validation of preconditions are often a thing that isn't done to effectively in the wild. Would a parameter non null modifier that quickly and cleanly threw a NullPointerException on method invocation be a useful thing? Something along the lines of
obj.doSomething(Integer !itemId )
where the exclamation mark signals non-nullability? A nice side effect would be that the optionality of parameters would be self documenting in the declaration.
-Default final method parameters To make code more easily understandable and to avoid reassignment bugs, method parameters could be final as default. The obvious downside would of course be that whenever manipulation of parameters is needed, a local copy is needed.
Hum, não acho que isso possua um significado pratico, especialmente porque o compilador pode tratar isso automaticamente, se já não o fizer, então, alterações na linguagem em algo que pode ser automatizado apenas complica a vida de programadores iniciantes. Imagine o cara receber um erro de compilação por causa de uma atribuição simples.
-Rebuilt access level modifiers Set private as default for everything, methods and variables. Whenever a broader scope is needed, it should be declared. The existing access modifiers are to few and not very useful in many situations. Rebuild the access modification system with for example:
private (default)
child (only for class and subclasses)
package (as before)
related (child + package)
public (as before)
Tambem acho o modificador default meio inutil, claro, vc não precisa escreve-lo, mas precisa entende como ele funciona. Como eu praticamente não uso o modificador default, não faz muito sentido para mim que ele exista. De qualquer modo, as proposta dele parece complicar as coisas e não simplificar.
-Add "test" access modifier Although access to private variables and methods can be done through reflection, it would help a lot to make it possible to reach the inner workings of a class for testing purposes. Add a special "test" access modifier, make the test class adhere to a special contract and voila, the class is accessible for testing purposes but nowhere else where it isn't intended.
Argh, melhor criar mocks do que misturar as classes com seus testes!
-Instances can access all other instance variables of the same class, despite private modifier. Although a small and trivial thing, it does break the encapsulation for distinct objects. Should a car have access to other cars internal state, just because of its car like qualities?
Hum, não ia dar muito trabalho para o ambiente de runtime não? Haja stack para uma instancia conhecer todas as outras, qual a utilidade de uma coisa assim? Para que uma instancia de Car iria querer saber que dados há em uma outra instancia? Como ele acessaria uma instancia especifica?
-Stronger encapsulation rules Although I'm not quite sure how the encapsulation and inheritance could be improved, I get a feeling that I'm exposing the internal structure of a class in a way that I'm not quite comfortable with when I (not so often) make use of "classic" inheritance. Interfaces and abstract classes are better approaches, but the normal inheritance IS an integrated part of Java and it's very easy to abuse in quite horrifying ways that can make code extremely brittle.
Hierarquias complicadas podem ser feitas com classes abstratas tambem. Alias, eu tento evitar herança sempre que possivel, mas não entendi que problemas ele teve.
-Catch for several exception types The times I've been adding exception after exception after another just to do the same thing are numerous. Please just give me a catch(IllegalargumentException, NullpointerException e) and things will look so much nicer.
Isso eu gostaria MUITO de ver. MUITO mesmo! Eu sentia falta em Java mesmo antes de conhecer Ruby. Acho sinceramente que catch em mais uma exception não complicaria o Tiger e já deveria existir no Java 5. Um colega chegou a argumentar comigo que poderiam abusar disso fazendo um catch pegar trocentas exceptions, mas para mim, isso não é muito diferente de ter varios throws na assinatura do metodo. Mesma coisa, se abusam de um, vão abusar de outro, e se um já existe, por que não colocar um catch para recupera mais de uma exception?
-Method level catch clause If it would be possible to add method handling after the method body, the logic of the method would often be so much clearer and easier to follow than when your catches are sprinkled throughout the metod. It could be something along the lines of:
public void callMe(...){
...
}catch(SQLException e){
//Do method handling
}
Caramba, isso eu não gostaria de ver! Melhor fazer o tratamento de exceptions dentro do metodo mesmo, ou em quem faz uso de tal metodo. Especialmente se as classes clientes tomam decisões diferentes para cada exceptions não tratada dentro do metodo usado.
-Pre and post conditions Along the same lines of method level catch blocks, pre and post conditions could be moved to the end of the method to isolate the main body of the method to make the logic easier to read. The pre and post blocks would have access to all parameters of the method that would be reachable from the top level of the method body:
public void callMe(String arg){
//Main logic
}pre{
if(arg == null){
//Throw exception
}
}post{
//More conditions...
}
Sem opinião clara a respeito dessa, mas a principio não me parece algo imprescindivel.
-More rigid primitive casting structure Remove almost all possibilities to cast between different primitive types. The casting rules are quite many and are very different to keep track of for new users and are of not a lot practical use in my experience. Removing them would make it easier for beginners. In the rare case where primitive type casting is needed, the wrapper classes could be extended with special casting methods that then could be learned on a need to know basis.
Blargh, adeus backward compatibility. Não gostei dessa tambem.
E vcs? Quais opiniões a respeito disso? Que outras mudanças vcs gostaria de ver na linguagem? Do que sentem falta?
Para aumentar a velocidade? Os objetos poderão ser modificados, mas as primitivas não? Sei lah
- Rebuilt access level modifiers
Concordo totalmente.
- Add "test" access modifier
Como o Jack disse, testes e classes não combinam.
- Instances can access all other instance variables of the same class, despite private modifier
Concordo, encapsulamento ROOOX
Stronger encapsulation rules
Não entendi o que ele quer
Catch for several exception types
Realmente é util e babaca de alterar.
Method level catch clause
Podre!
Pre and post conditions
Podre também! Na literatura isso se chama MetaClasses, onde você trata as exceções fora do método. Em um lugar bem longe da tua lógica.
More rigid primitive casting structure
Não muda nada pra mim.
Eu adicionaria:
- Suporte a primitivas do tipo BigDecimal e BigInteger. Fazer cálculos com essas classes é muito chato!
- Suporte a algum tipo de pesquisa nativa dentro das collections (Isso dá um baita trabalho)
- Melhorias nas classes de reflection. Talvez adicionar a Apache BeanUtils no JRE do Java.
Para aumentar a velocidade? Os objetos poderão ser modificados, mas as primitivas não? Sei lah
Como eu disse antes, o compilador pode fazer isso sozinho. Alem disso, esse tipo de otimização é praticamente imperceptivel nas vms mais novas. Eu só declaro parametros como final quando preciso usa-los dentro de uma inner class.
vfpamp
Catch for several exception types
Realmente é util e babaca de alterar.
Porra, muito util isso mesmo! E como vc disse não daria tanto trabalho para alterar e a comunidade entender como funciona.
vfpamp
- Suporte a primitivas do tipo BigDecimal e BigInteger. Fazer cálculos com essas classes é muito chato!
Isso seria legal, mas acho que Java precisaria de lazy evaluation para tratar bem esse tipo de calculo. Ou não tem relação uma coisa com a outra?
vfpamp
- Suporte a algum tipo de pesquisa nativa dentro das collections (Isso dá um baita trabalho)
Essa eu não entendi. Vc queria fazer algo como:
?
vfpamp
- Melhorias nas classes de reflection. Talvez adicionar a Apache BeanUtils no JRE do Java.
Hum, acho que só precisava melhorar a parte de introspecção. Que partes do BeanUtils vc gostaria de ver nas core libraries?
Isso seria legal, mas acho que Java precisaria de lazy evaluation para tratar bem esse tipo de calculo. Ou não tem relação uma coisa com a outra?
Aí eu não sei. Só sei que: 1.56 + 1.33 = 1.89
Essa eu não entendi. Vc queria fazer algo como:
Algo assim:
Que partes do BeanUtils vc gostaria de ver nas core libraries?
Tipo, busca de métodos sem case-sensitive, gets e sets do Field, invoke com parametro null, clone completo automático, etc. _________________Vitor Pamplona
http://vitorpamplona.com @vitorpamplona
Pode esquecer. Isso implicar mudar muito a linguagem, se vc pudesse passar as queries como String sim, mas dessa maneira, pode esquecer. Dava para fazer algo assim sem muitas broncas usando OGNL e o CollectionUtils.
- Instances can access all other instance variables of the same class, despite private modifier
Isso não seria mal. Só tem que tomar cuidado pra não quebrar a compatibilidade.
Stronger encapsulation rules
?
Catch for several exception types
Bom.
Method level catch clause
Tosco.
Pre and post conditions
Acadêmico, digo, complicação demais.
More rigid primitive casting structure
Sei lá.
vfpamp
- Suporte a primitivas do tipo BigDecimal e BigInteger. Fazer cálculos com essas classes é muito chato!
Talvez. Mas mudaria a especificação de tudo, da JVM, do bytecode e da linguagem. Mas acho que é possível acrescentar sem quebrar a compatibilidade.
vfpamp
- Suporte a algum tipo de pesquisa nativa dentro das collections (Isso dá um baita trabalho)
Eca!
No lugar disso, melhor o suporte a Closures! É bem mais útil, e daria pra fazer pesquisas e iterações que nem no Groovy.
Mas esse seu 'where' aí é muito tosco (argh, SQL embutido não!!!), além de quebrar completamente a compatibilidade (quem aí nunca usou variáveis de nome 'where' em código JDBC?).
vfpamp
- Melhorias nas classes de reflection. Talvez adicionar a Apache BeanUtils no JRE do Java.
Hum... é, talvez. _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
BigDecimal Talvez. Mas mudaria a especificação de tudo, da JVM, do bytecode e da linguagem. Mas acho que é possível acrescentar sem quebrar a compatibilidade.
Não quebra não, já que tem L para longo, poderia ter um B de BigDecimal. E isso pode ser implementado no AutoBoxing nem precisa alterar a JVM.
Sobre a SQL embutida, não precisa ser assim, mas tem que haver um meio de fazer algo semelhante (sem ser com Strings). Se a linguagem OO não evoluir outra linguagem irá passar por cima dela. Quantos não usavam "enum" antes do 1.5 e "assert" antes da 1.4?
Falando em SQL embutida, li em algum lugar que estão propondo embutir SQL e XML no Java 7 (ou 8 ). o que voês acham disso? Não iria complicar muito a linguagem?
Grato, _________________Rafael U. C. Afonso
[i]Where is debug?
Debug is on the table[/i]
Sobre a SQL embutida, não precisa ser assim, mas tem que haver um meio de fazer algo semelhante (sem ser com Strings). Se a linguagem OO não evoluir outra linguagem irá passar por cima dela. Quantos não usavam "enum" antes do 1.5 e "assert" antes da 1.4?
Acho que, pra coisas desse tipo, o melhor seria ter um (pré-)compilador, tipo AspectJ, e não entupir a linguagem (que é de uso genérico) com tranqueiras específicas de bancos de dados (aliás, qual o dialeto que seria suportado?...) _________________In fact, people who study design methods without also practicing design are almost always frustrated designers who have no sap in them, who have lost, or never had, the urge to shape things. Such a person will never be able to say anything sensible about "how" to shape things either. (Christopher Alexander)
E quem disse que era específica para banco?? Eu falei query em Colections
Tipo, você pode facilmente filtrar a lista que está no TableModel sem ter que ir ao banco. +/- Como o TQuery.filter do Delphi _________________Vitor Pamplona
http://vitorpamplona.com @vitorpamplona
hum.... Embora que muda bastante coisa, não seria mal esse negócio de set e get
Pois é, eu tenho umas classes que possuem gets/sets apenas por causa de um framework ou outro, mas eles deixam o codigo muito poluido, especialmente quando vc não os deixa separados (eu sempre os coloco no final da classe). Mas, ter uma sintaxe mais simples para escrever isso e deixar o codigo mais claro ajudaria um bocado.
Podre também! Na literatura isso se chama MetaClasses, onde você trata as exceções fora do método. Em um lugar bem longe da tua lógica.
Que literatura? Pré/Pós condições e invariantes são os pilares de Design by Contract. É útil quando não obrigatório e bem utilizado.
Metaclasse é um conceito bem diferente, que pode até ser utilizado para aplicar pré e pós condições, assim como pode implementar com aspectos, manipulação de bytecodes, geraçãod e código.... ou, como em Eiffel, na própria linguagem, que é a proposta do autor. _________________Phillip Calçado "Shoes"
http://www.fragmental.com.br
Poisé shoes, a idéia era essa mesmo, usar meta-classes e meta-objetos para criar essas pré e pós condições em hierarquias padronizadas. Bem melhor que esse troço aih
jack_-_ganzhaPosts:4191
Uma discussão interessante sobre mudanças na linguagem Java apareceu no JavaLobby esses dias. O autor argumenta que faltam algumas construções que tornaria Java melhor e fala sobre como deveriam ter entrado já no Tiger. Como alterações na linguagem não foram planejadas para o Mustang, se alguma dessas mudanças vier, só as veremos bem mais no futuro. Os novos recursos e porque o autor acha que eles devam ser incorporados logo abaixo: