Na verdade eu postei errado, era para ser:
Area a=new Area();
e aí na chamada de método:
a.convertTo(BD valor,Unidade unidadeOriginal,Unidade unidadeParaConversao);
ou passar o valor no construtor:
Area a=new Area(BD valor);
e fazer uma chamada tipo a.convertTo(Origem,Destino);
Sacou?E não podemos usar um construtor só com BD, pq se o cara passa um outro tipo de valor teremos problemas.Podemos fazer um super.toString() quando necessário com a classe extendendo BigDecimal.
Ah, abri um blog para o projeto:
http://brazilutils.blogspot.com/
Assim quando o guj tiver down, discutimos lá…
[quote] Ah, abri um blog para o projeto:
http://brazilutils.blogspot.com/
Assim quando o guj tiver down, discutimos lá…[/quote]
Bem, aqui é tudo bloqueado e pouca coisa liberada, e essa infelizmente não é umas das poucas coisas…
[quote] Na verdade eu postei errado, era para ser:
Area a=new Area();
e aí na chamada de método:
a.convertTo(BD valor,Unidade unidadeOriginal,Unidade unidadeParaConversao); [/quote]
Bom, nada contra um método assim, mas se deve passar tudo isso, então ele deveria ser estático certo? Tipo:
Area.convertTo(BD valor,Unidade unidadeOriginal,Unidade unidadeParaConversao);Acho que a unidade deve fazer parte mesmo da área, já que sem ela o que tem ali é apenas um número sem um maior significado… mas essa é a minha opinião só, e o pessoal não vem nem dar opinião tá louco…
flw
Y!Mas não é lá muito elegante…
Por isso eu defendia cada unidade como classe e Área como superclasse de cada unidade.Fica mais claro a conversão de Hectare.convertTo(Unit unitToBeConverted) do q Area.convertTo…
Depois me “bombam” via email dizendo que eu tomei alguma decisão totalitária. Esse é um dos motivos na qual eu e o Douglas resolvemos tocar o projeto “na surdina”.Muito oba-oba e pouca contribuição(não desmerecendo os que já contribuíram como o Dango).Eu vou mandar um email explicando para o pessoal dar idéias e tal, mas eu quero acertar os detalhes mais rápido possível.Em Setembro tem que rolar um “mini-release” ao menos.A falta de um PM prejudica bastante também.
dudaskank,
sugestões do Cv:
Hectare h = new Hectare(valor);
MetroQuadrado m2 = (MetroQuadrado) h.to(MetroQuadrado.class);
Passando ao método to a classe via reflection.(mantendo o extends BigDecimal e implementando uma interface de constantes).
Ele ainda sugeriu Generics:
public <T extends Area> T to(Class<T>) {…}
Mas isso mandaria para o saco a galera do 1.4 para baixo…
[quote=Ironlynx]dudaskank,
sugestões do Cv:
Hectare h = new Hectare(valor);
MetroQuadrado m2 = (MetroQuadrado) h.to(MetroQuadrado.class);
Passando ao método to a classe via reflection.(mantendo o extends BigDecimal e implementando uma interface de constantes).
Ele ainda sugeriu Generics:
public <T extends Area> T to(Class<T>) {…}
Mas isso mandaria para o saco a galera do 1.4 para baixo…[/quote]
Hmm, eu acho que é por aí, mas eu acho que é mais complicado assim. Apesar de nem ser tão diferente do que fiz…
Essa interface de constantes até acho que não precisa desse jeito, já que vai estender Area pode colocar as constantes nela também.
Ah, mas isso é normal, não tem como agradar a todos… e o pessoal fala que vai contribuir mais na base da empolgação mesmo, aí chega na hora e não sabe o que fazer… parece eu no Sábado rsrsrs
flw
[quote=Ironlynx]dudaskank,
sugestões do Cv:
Hectare h = new Hectare(valor);
MetroQuadrado m2 = (MetroQuadrado) h.to(MetroQuadrado.class);
Passando ao método to a classe via reflection.(mantendo o extends BigDecimal e implementando uma interface de constantes).
Ele ainda sugeriu Generics:
public <T extends Area> T to(Class<T>) {…}
Mas isso mandaria para o saco a galera do 1.4 para baixo…[/quote]
Por isso que eu digo que Java devia ter diretivas de compilação…
Ola Pessoal onde eu abaixo a API BrazilUtils???
[quote=correainfo]Ola Pessoal onde eu abaixo a API BrazilUtils???
[/quote]
Pior hein, já querem botar o bicho feio chamado closures, por que não algo pra fazer:
#ifdef JAVA_5
public <T extends Area> T to(Class<T>) {...}
#endif
hehehe
Pô, closures é lindo e mais velho que o pterodáctilo! 
[quote]Essa interface de constantes até acho que não precisa desse jeito, já que vai estender Area pode colocar as constantes nela também.
[/quote]
Opa, eu faço Area extender BD e implementar a interface de constantes.
Acho legal uma interface só de constantes pq é algo que teoricamente pode mudar mais.E a interface ficaria um nível acima na escala de packages, tipo em org.brazilutils.metrics, e não em org.brazilutils.metrics.br pq se alguem for utilizar em outros packs de outros países, estará ok(claro q eu mantenho essas constantes em inglês, mas não altera muita coisa).
O único problema dessa abordagem:
MetroQuadrado m2 = (MetroQuadrado) h.to(MetroQuadrado.class);
é o custo do reflection!Mas creio que não é nada tãaao significativo.
E aí, galera? Beleza?
Primeiro, parabéns pela iniciativa! Tenho trocado idéia com o Ironlyns, já estou cadastrado no java.net e fiquei responsável pelo pacote currency.
Estou preparando aquela classe que deixa valores monetários escritos por extenso.
Enfim, estou criando dois métodos sobrecarregados:
- public static String porExtenso(BigDecimal currency);
- public static String porExtenso(String currency);
*EDITADO: os métodos porExtenso não serão estáticos. Há bons motivos de sobra para essa decisão.
Deixei os nomes em português porque não tenho a menor noção de como fazê-los ter sentido em inglês.
A minha idéia é fazer os métodos verificarem se os parâmetros tem escala dois ou três. Se tiver outra escala, maior que três por exemplo, joga uma excessão.
Mas, meu problema mesmo é com as casas decimais. Eu preciso separar o valor inteiro do decimal. Ex: R$ 6.432,24 ficaria 6432 numa variável e 24 noutra.
Tive uma idéia, mas acheio tosca. Teria que converter para String, encontrar a vírgula e separar os “dois lados da moeda”… Mas daí, teria que voltar pra BigDecimal novamente para fazer os cálculos.
Vocês têm alguma outra idéia?
T +!
Lembre-se de deixar no package currency.br, vai que alguém resolver fazer uma versão para dólares/libras/etc.
Boa.
[quote]
Mas, meu problema mesmo é com as casas decimais. Eu preciso separar o valor inteiro do decimal. Ex: R$ 6.432,24 ficaria 6432 numa variável e 24 noutra.[/quote]
Aquela classe que mostrei não lhe ajudou?
Esse é o método tradicional.Lembre-se de usar um StringBuffer(eu iria dizer para usar StringBuilder mas há muitos 1.4 ainda…) na concatenação.
Bem, se você já tem ele em BigDecimal E puder usar java 5, tem os métodos:
public BigDecimal[] divideAndRemainder(BigDecimal divisor)
public BigDecimal[] divideAndRemainder(BigDecimal divisor, MathContext mc)
Caso não, apesar de provavelmente ser parecida a classe que o Ironlynx deve ter te mandado, veja se isso ajuda:
[code]
package teste.guj;
import java.math.BigDecimal;
import java.math.RoundingMode;
public class TesteBigDecimalResto {
public static void main(String[] args) {
BigDecimal n = new BigDecimal(“123456.789”);
BigDecimal parteInteira = n.setScale(0, RoundingMode.DOWN);
BigDecimal parteDecimal = n.subtract(parteInteira).movePointRight(n.scale());
System.out.println(n);
System.out.println(parteInteira);
System.out.println(parteDecimal);
}
}[/code]
[quote=Ironlynx]Lembre-se de usar um StringBuffer(eu iria dizer para usar StringBuilder mas há muitos 1.4 ainda…) na concatenação.
[/quote]
Não posso mesmo usar o que é específico do Java 5?! Mas as classes do Douglas já usam Enum!
O que eu penso é que temos que tirar o melhor possível do Java, até para eliminar certas barreiras… Sem querer ser chato, mas quem tiver problemas de compatibilidade que veja o código e adapte as classes de acordo com a sua necessidade. E se mandasse pra gente melhor ainda! Já teríamos a nossa própria versão de Vector vs. ArrayList!
Chefe, você não pode dar um jeito? Compatibilidade é mais importante que desempenho mesmo? Vou esperar sua resposta para começar a programar.
[quote=dudaskank]Bem, se você já tem ele em BigDecimal E puder usar java 5, tem os métodos:
public BigDecimal[] divideAndRemainder(BigDecimal divisor)
public BigDecimal[] divideAndRemainder(BigDecimal divisor, MathContext mc)[/quote]
Valeu! Como disse, espero poder usar o que já está no Java 1.5.
Tá ok… vcs venceram!Liberado o uso do Tiger!
Eu acho Desempenho mais importante que retrocompatibilidade, mas se preparem que eu vou redirecionar eventuais reclamações via email direto para suas respectivas caixas… :lol:
[quote=Ironlynx]
Tá ok… vcs venceram!Liberado o uso do Tiger!
Eu acho Desempenho mais importante que retrocompatibilidade, mas se preparem que eu vou redirecionar eventuais reclamações via email direto para suas respectivas caixas… :lol: [/quote]
Pode mandar! Eu trabalhei numa empresa grande e burocrática, já aprendi como agir nesses casos: é só fazer uma resposta padrão! hehe
Sr. ou Sra. Fula de Tal (Nome aqui! Não enviar Fulano de Tal!)
Entendemos a sua preocupação e sua vontade de usar essa incrível biblioteca de utilidades.
Mas, no momento não podemos atendê-lo. Isso porque ainda não descobrimos uma maneira de agradar a gregos e troianos. Não ficaremos ofendidos com os seus impropérios porque sabemos que é mais fácil nos xingar que xingar os seus chefes - a não ser, é claro, que você xingue seu chefe por dentro! E é mais fácil seus chefes fazerem você usar Java 1.4 (ou 1.3!) do que convecer os clientes da sua empresa a colocar a mão no bolso e usa o Java 5.
É uma situação triste, lamentamos por isso, mas não podemos fazer nada. Obrigado por nos deixar saber o que você pensa (mesmo que isso não adiante nada)!
Mas as nossas portas estão abertas para você. Além de chorar, você também pode coloborar com o BrazilUTILS! Descubra como fazer (o objeto da reclamação aqui) de forma compatível com a versão 1.4 e mande para o nosso CVS no java.net.
Atenciosamente!
Rafael.
Hahaha, muito boa essa carta Rafael!
Bem, eu ainda não faço parte oficialmente do projeto, então não adianta mandar e-mail pra mim hehehehe, manda tudo pro Rafael rsrsrs.
Aliás, vou ver se encontro onde começa a participar, pelo menos com alguns códigos acho que consigo hehe.
Assim eu aproveito e pego experiência pra começar um projeto que to querendo colocar lá também 
flw
Ironlynx e Rafael,
Acho que a questão de usar 1.4 ou 5.0 deve ser pensada com mais calma. Lembrem-se que fazer na 5.0 vai impedir que muita gente use a API. Quanto a questão do desempenho, acho que algum ganho nesse sentido está muito mais ligado em como o sistema cliente é feito do que nas APIs que são rápidas ou lentas. As funcionalidades não me parecem críticas: validação, código de barras; cálculos talvez.
Pessoalmente acho que deveríamos fazer na 1.4 e aumentar o leque de pessoas usando a API e dando retorno.
Tive uma experiência aqui no projeto tremendamente desagradável de ter que desfazer código feito em 5.0 para 1.4 justamente porque o servidor de aplicação ainda não estava pronto para 5.0. Isso é uma realizade bastante comum.
Nós nem fizemos um levantamento de qual parte da API precisaria mesmo se feita em 5.0, acho que devemos começar por aí.
Realmente não são críticas.Mas o problema que eu tô vendo é que liberar uma parte em Java5 vai tornar o projeto inteiro java5 uma vez que não teremos(em princípio) libs separadas…
dudansk, pq vc não se filia ao projeto e tenta ajudar o Rafael nessa empreitada?
Na verdade, vc já disse(a parte de cálculos até pq operações com BigDecimal são lentas).
Ironlynx, uma sugestão:
Que tal editar sua primeira mensagem neste post colocando o link para o projeto e um resumo do que ele faz e qual a versão mais recente. Fica mais fácil para quem entrar nesse post saber que o projeto não está morto e que existe release.
[]'s