Java não possuía qualquer mecanismo de persistência diferente do JDBC. Alguém teve a idéia de criar uma forma de fazer isso, sem precisar que o programador criasse queries. O Hibernate é um exemplo disso e, depois de alguns anos, o JPA foi criado.
Se não está satisfeito, se acha que seria melhor de outra forma, camarada, pare de reclamar aqui e vá procurar os meios adequados.
Se não for aceita a sua idéia, ao menos você tentou. Simples. é apenas isto que eu estou tentando dizer desde que respondi a primeira vez. Manja?
[quote=drsmachado]Veja que o comportamento do operador ‘+’ é diferente em cada caso.
Isso pode dar a interpretação de ‘muitas formas’…
Eu, particularmente, discordo. Enfim.[/quote]
Isso, foi exatamente isso que eu quis dizer.
Eu discordo de que sobrecarga seja uma forma de polimorfismo, justamente porque a implementação pode mudar.
[quote=Rafael Rossignol]@drsmachado
Ah, tem mais um ponto.
No mundo real, tem programador ruim ganhando bem, e programador bom ganhando mal.
Quando você aprende a programar, vocÊ aprende a programar, e não gerenciar sua carreira ou fazer marketing pessoal.
Então, não podemos dizer que é culpa do mercado que paga pouco pra programador ruim. O cara pode ser excelente programador, mas vem de uma familia pobre e tem que aceitar o primeiro emprego que oferecem pois tem gente dependendo dele, o cara pode não poder se arriscar.
Então tente não ser injusto com a situação das pessoas, você não sabe como elas vivem e as dificuldades que tiveram ou têm na vida.[/quote]
Mas aí é que está, mesmo o cara que vem de família humilde, que necessita de qualquer oportunidade, sendo bom programador, logo percebe que pode crescer no mercado (true own history). Se você não conhece seu potencial ou é ruim mesmo, aí não adianta saber, precisa de marketing.
Além do mais, a maior culpa é de quem contrata. Enquanto um cara bom mesmo pede X, um cara ruim pede X/2. Logo, o sujeito pensa “posso contratar esse e economizar uma grana”. Aí começa a nivelar o mercado por baixo…
[quote=digaoneves][quote=drsmachado]Veja que o comportamento do operador ‘+’ é diferente em cada caso.
Isso pode dar a interpretação de ‘muitas formas’…
Eu, particularmente, discordo. Enfim.[/quote]
Isso, foi exatamente isso que eu quis dizer.
Eu discordo de que sobrecarga seja uma forma de polimorfismo, justamente porque a implementação pode mudar.[/quote]
Mas isso também se aplica a varias outras coisas:
class Calculadora {
double soma(double valor1, double valor2) {
return valor1 + valor2;
}
double soma(int valor1, int valor2) {
return valor1 - valor2;
}
}Cabe ao programador decidir isso.
O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.
Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …
Ainda sobre essa discussão de “pensar ou não pensar” orientado a objetos que o drsmachado tanto frisa, lembre-se que a linguagem de programação Java não é 100% OO, temos com exemplo a classe String e seus métodos estáticos, e por ai vai, então violar OO em alguns pontos é uma prática bem disseminada entre os desenvolvedores.
Já questão de legibilidade não eh um grande problema quando se domina a API que esta utilizando, porém, o que o proprietário do post quis dizer foi que mesmo em OO podemos utilizar de um mecânismo de adição para determinados tipos de objetos, em matemática existe isso, por exemplo: sejam A e B dois conjuntos do plano cartesiano, e seja “x” e “y” elementos de A e B, respectivamente. Todos sabem desde o colégio que podemos efetuar x + y, e eles não são números (escalares).
abrs…
Mude para C++ , ou C# , ou praticamente qualquer outra linguagem moderna 
A linguagem Java (não sei se intencionalmente ou não) acabou ganhando essa característica de ser totalmente “formal”, “quadrada”. Acho que nunca terá sobrescrita de operadores, nem acesso a coleções no estilo array, nem funções anônimas, nada dessas features descoladinhas que vemos por aí.
De fato, não tem nada a ver com orientação a objeto ou não, é questão de estilo.
[quote=Sem_Nome]Mas isso também se aplica a varias outras coisas:
class Calculadora {
double soma(double valor1, double valor2) {
return valor1 + valor2;
}
double soma(int valor1, int valor2) {
return valor1 - valor2;
}
}Cabe ao programador decidir isso.
O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.[/quote]
Com seu exemplo você está exemplificando o meu ponto de vista. É por isso que eu não concordo que sobrecarga seja polimorfismo, apesar dependendo da implementação, pode dar essa ilusão.
Quanto a sobrecarga de operadores, existem linguagens que rodam na JVM e o fazem, Scala é um exemplo.
O criador do Scala o criou para provar que é possível uma linguagem ser orientada a objetos e também funcional.
E quem viu aquela declaração do James Strachan (Criador do Groovy), percebe o quanto Scala está impressionando.
Agora quanto ao Java seguir esse caminho, realmente eu não sei, não encontrei nenhuma JSR que indicasse isso.
@Aleksandro
era esse o ponto que queria chegar, aqui o administrador tem o pé atras de fazer lógica de negocios em java, e sei que esse é um dos motivos.
o @Sem_nome disse “O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.”
Eu queria entender que tipos de impedimentos a sobrecarga de operadores poderia causar, visto que os metodos antigos poderiam continuar existindo.
aí que tá o ponto, eu não entendi porque isso ainda não foi implementado no java, sendo que é util, é legal, é fácil (não sei se é fácil de implementar, estou falando da usabilidade)
[quote=digaoneves][quote=Sem_Nome]Mas isso também se aplica a varias outras coisas:
class Calculadora {
double soma(double valor1, double valor2) {
return valor1 + valor2;
}
double soma(int valor1, int valor2) {
return valor1 - valor2;
}
}Cabe ao programador decidir isso.
O único problema que vejo com sobrecarga de operadores é com frameworks. Pode tornar algumas coisas confusas.[/quote]
Com seu exemplo você está exemplificando o meu ponto de vista. É por isso que eu não concordo que sobrecarga seja polimorfismo, apesar dependendo da implementação, pode dar essa ilusão.
Quanto a sobrecarga de operadores, existem linguagens que rodam na JVM e o fazem, Scala é um exemplo.
O criador do Scala o criou para provar que é possível uma linguagem ser orientada a objetos e também funcional.
E quem viu aquela declaração do James Strachan (Criador do Groovy), percebe o quanto Scala está impressionando.
Agora quanto ao Java seguir esse caminho, realmente eu não sei, não encontrei nenhuma JSR que indicasse isso.[/quote]
Entendo. Achei que você se referia apenas a sobrecarga de operadores.
Não há nada no Java que impossibilite uma forma limitada de operator overloading para BigDecimal.
O único problema é com a divisão, porque o método “divide” com apenas 1 parâmetro é normalmente inútil na prática (já que ele provoca uma exceção quando você tem como resultado uma dízima periódica).
O correto, a meu ver, é ter um tipo “Currency” na linguagem (assim como existe um no C#), que é o principal caso de uso de BigDecimal. O BigDecimal “em si”, devido ao fato de ser muito geral, deveria ser deixado como está.
Esse Currency seria um BigDecimal mas com as operações usando sempre o MathContext.DECIMAL128 (que é o formato IEEE 754R Decimal128 ) . Como o MathContext seria fixado, é possível otimizar as operações nesse caso.
Pense bem - só porque a linguagem é orientada a objetos você precisa trabalhar com dados imutáveis como se fossem objetos também? Acho um pouco radical (xiita) demais. Eu prefiro que a linguagem reflita a linguagem que se usa no domínio do uso. Senão, você faria tudo como objetos, e você teria sempre que escrever:
int x = 3.add (4).mul (5).div (7).chs();para representar algo tão simples como -(3+4)*5/7.
[quote=Aleksandro]Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …
[/quote]
Não acredito que Java seja a melhor opção para uma aplicação voltada a rotinas numéricas, por exemplo: resolver equações diferenciais usando Java não é computacionalmente inviável.
abrss
@gomesrod
fala pro meu chefe que agora vamos desenvolver o ERP aqui da empresa em C++
@entanglement
concordo com você
@digaoneves
as closures deram tão certo nas linguagens de script que foram para o java 
@Vini Fernandes
Bom, 90% dos sistemas que temos por aí pra desenvolver são ERPs, sistemas de informação convencionais, etc…
Qual as primeiras linguagens que vem em mente? java? C#?
Num país como o nosso, onde as leis fiscais e impostos são a m… que são (desculpe o palavreado), cai nesse ponto.
Eu nem isso, pense num sistema de MRP ou num simples sistema de estoque com valorização de estoque, as vezes tem que fazer contas um pouco mais elaboradas, e tem 12 campos de impostos cada vez, se fosse um único campo, até vá la, usar os metodos para fazer os cálculos.
Imagina você calcular base e valor de: ipi, icms, icms-st, pis, pis-st, cofins, cofins-st, mva de cada um, e por aí vai.
Só acho que seria um grande facilitador, talvez uma nova classe como foi sugerido, como tem no C#, pra trabalhar com grana.
[quote=Rafael Rossignol]@digaoneves
as closures deram tão certo nas linguagens de script que foram para o java ;)[/quote]
Você quis dizer vão pro Java, né? 8)
Isso só será lançado no Java 8, vai saber quando alguém realmente vai usar isso em um projeto.
Mas não posso negar que é um avanço.
[quote=Rafael Rossignol]@gomesrod
fala pro meu chefe que agora vamos desenvolver o ERP aqui da empresa em C++[/quote]
Não sei se vc me entendeu ou não, mas só para o caso de não ter ficado claro era brincadeira hein !
Agora, se quiser pensar em uma solução mais palpável: (nunca fiz nada parecido, mas sei que teoricamente é possível)
E se os componentes responsáveis pelos cálculos “chatos” fossem escritos em uma linguagem diferente?
Há pelo menos três maneiras para isso:
uma é usar o recurso de interpretação de linguagens de script
outra é usar uma linguagem suportada pela JVM e que possua os recursos desejados.
e a terceira é criar seu próprio mecanismo de interpretação de expressões e resolução de cálculos, onde você entraria com uma expressão escrita de forma mais natural.
@gomesrod
a segunda solução acho uma solução legal, já havia pensado nisso
Escrever EJBs em groovy ou scala talvez
[quote=Vini Fernandes][quote=Aleksandro]Eu já vivenciei profissionalmente , uma situação onde o sistema deveria calcular apólices de seguro , no caso o cliente usava oracle como banco de dados , na época a equipe da empresa onde eu trabalhava , chegamos a ter discussões calorosas, pois de um lado havia alguns evangelistas java e de outro os funcionais que queriam que a coisa fosse feita da melhor forma possível, chegamos a implementar a rotina de cálculo em java e fizemos algumas procedures no oracle usando pl/sql para ver não só a performance e sim o tempo de resposta entre uma escolha e outra…e para nossa surpresa o cálculo no java ficou muito complexo e lento , devido ao fato de ter esta dificuldade de se fazer cálculos complexos … enfim …chegamos a conclusão que naquele momento era muito mais interessante ter o código no banco de dados do que na aplicação …enfim , esta decisão foi por conta principalmente da estrutura que o cliente tinha e que sabíamos que este cliente não trocaria seu banco da dados a curto prazo …
Isto ocorreu em 2005 … vejo que houve uma evolução da linguagem neste período, mas entendo que nós programadores temos que nos adaptar ao que o negócio da empresa pede …então acredito que no caso do bigdecimal , por si só já foi uma evolução , mas acredito que o pessoal da JCP se esbarrou em outras coisas que impossibilitam este tipo de operação … penso eu …
[/quote]
Não acredito que Java seja a melhor opção para uma aplicação voltada a rotinas numéricas, por exemplo: resolver equações diferenciais usando Java não é computacionalmente inviável.
abrss[/quote]
Sim, concordo com você, na verdade quando mencionei o meu case que foi real, na época 2005 …rs…nem faz tanto tempo assim, java no brasil era imaturo ainda e claro , mesmo assim, perdemos tempo criando ambos os códigos em paralelo (java e pl/sql) e testamos ambas as situações até o fim do processo, onde concluímos que naquele momento era mais viável para aplicação e para o negócio a utilização das procedures em pl/sql. mas depois de alguns meses evoluimos o código feito em java e a diferença não era tão assustadora , uma vez que também havia evoluido os frameworks (struts 1.2 e hibernate) enfim …acho sim , que nós devemos nos orientar no que é bom para a empresa e ou aplicação e não ficar se escorando no que eu sei apenas , ou no que eu defendo …enfim é mera opinião …gosto de java , mas se eu souber fazer tal pedaço de código em outra linguagem e que se integre a minha aplicação sem problemas e seja melhor que fazer em java e minha equipe saiba o que eu estou fazendo , não vejo nenhum problema, por isto sempre digo , aprenda mais de uma linguagem e seja feliz …
e para finalizar , certa vez eu li aqui no guj uma frase assim:
Não sei vocês, mas sou só eu que vejo “algo errado” na legibilidade/facilidade destes códigos que realizam o mesmo cálculo?
[code]
//double
double resDouble = ( 5+3*1.3+(1.1+0.1) );
//BigDecimal
BigDecimal resBigD = new BigDecimal(“5”).add(new BigDecimal(“3”).multiply(new BigDecimal(“1.3”)).add(new BigDecimal(“1.1”).add(new BigDecimal(“0.1”))));[/code]
realmente é muito mais simples e natural fazer o cálculo com BigDecimal… :shock: