Isso é sério?

Holy cow WTF??

Retirado do próprio fonte:

This is a generated class used internally during the writing of bytecode within the CallSiteWriter logic.

• This is not a class exposed to users, as is the case with almost all classes in the org.codehaus.groovy packages.
  
  
• The purpose is the reduction of the size of the bytecode. Consider creating a three element Object[] with null values:
  

Lembro-me de ter visto isso em algum lugar já, acho que no Apache Utils.

Não tinha lido os comentarios :oops:

Me lembrei do aluno que fez um println com os números de 1 a 100, onde o enunciado pedia exatamente que ele fizesse um código que imprimisse os números de 1 a 100…auhuahauhu

Agora, eu acho que se fossémos fuçar essas apis super consagradas acharíamos várias dessas coisas. Não tenho experiência nesse tipo de implementação, mas, o cara tá pensando a nível de bytecode, então, talvez pra quem esteja codificando tendo esse nível de preocupação seja algo realmente válido.

Eles fizeram isso por ser mais rapido que varargs

Os caras usando DefaultTableModel dá até estranheza

Exato, alias o varargs não é meramente um açúcar sintático ? como o ’ foreach’ que faz um iterator por debaixo dos panos.

Interessante, isso mostra que nem sempre o código mais enxuto e bonito é o mais rápido.

Nas chess engine profissionais é normal acontecer isso, priorizando sempre o máximo de desempenho em vez
de clareza no código.

Eu aplicava uma prova de seleção na qual criei um exercício que era basicamente o seguinte: “De 1 a 100: se o número for divisível por 3, imprima zag, se for por 5, imprima zug, se for por 3 e 5, imprima zagzug”

Um teste simples, idiota, no qual nada poderia dar errado. Eis que apliquei a um caboclo e DUAS horas depois recebo a seguinte resposta

for (int i = 1; i <= 100; i++) {
        if (i == 1) { }
        else if (i == 2) {} 
        else if (i == 3) { System.out.println("zag");}
        (...)
         else if (i == 5) { System.out.println("zug");}
         (...)
         else if (i == 15) { System.out.println("zagzug"); }
         (...)
         else if (i == 100) { System.out.println("zug"); }
}

Detalhe: este foi um dos poucos caras que CONSEGUIU fazer o teste.

Alguém sempre tem que fazer o trabalho sujo. Isso aí teve um bom motivo, diferentemente do trabalho sujo que nós vemos sendo feito por aí, que normalmente é preguiça ou workarounds para coisas que não precisavam.

kicolobo:

Eu aplicava uma prova de seleção na qual criei um exercício que era basicamente o seguinte: “De 1 a 100: se o número for divisível por 3, imprima zag, se for por 5, imprima zug, se for por 3 e 5, imprima zagzug”

Um teste simples, idiota, no qual nada poderia dar errado. Eis que apliquei a um caboclo e DUAS horas depois recebo a seguinte resposta

for (int i = 1; i <= 100; i++) {
        if (i == 1) { }
        else if (i == 2) {} 
        else if (i == 3) { System.out.println("zag");}
        (...)
         else if (i == 5) { System.out.println("zug");}
         (...)
         else if (i == 15) { System.out.println("zagzug"); }
         (...)
         else if (i == 100) { System.out.println("zug"); }
}

Detalhe: este foi um dos poucos caras que CONSEGUIU fazer o teste.

vai ver ele estava aprendendo a usar os operadores mas ainda não tinha chegado no %… :lol:

kicolobo:

Eu aplicava uma prova de seleção na qual criei um exercício que era basicamente o seguinte: “De 1 a 100: se o número for divisível por 3, imprima zag, se for por 5, imprima zug, se for por 3 e 5, imprima zagzug”

Um teste simples, idiota, no qual nada poderia dar errado. Eis que apliquei a um caboclo e DUAS horas depois recebo a seguinte resposta

for (int i = 1; i <= 100; i++) {
        if (i == 1) { }
        else if (i == 2) {} 
        else if (i == 3) { System.out.println("zag");}
        (...)
         else if (i == 5) { System.out.println("zug");}
         (...)
         else if (i == 15) { System.out.println("zagzug"); }
         (...)
         else if (i == 100) { System.out.println("zug"); }
}

Detalhe: este foi um dos poucos caras que CONSEGUIU fazer o teste.

Eita go horse!!

Nossa, que coisa mais thedailywtf

isso eh o maior go horse de todos os tempos.
nao sei, mas quanto mais lento é o varargs para fazer um bizonhice dessas. uns milesgundos. vou até medir para ver.
depois posto o resultado.

[]'s

mauricioadl:

isso eh o maior go horse de todos os tempos.
nao sei, mas quanto mais lento é o varargs para fazer um bizonhice dessas. uns milesgundos. vou até medir para ver.
depois posto o resultado.

[]'s

eu não consegui ver nenhuma possibilidade de usar akela classe.

alguem tem um exemplo de uso.

tipo

Object[] a = ArrayUtil.createArray(obj1, obj2, obj3);

seria isso?

Faco a mesma coisa no MentaLog para ele não produzir nenhum lixo:

http://mentalog.soliveirajr.com/mentalog-api/org/mentalog/VarargsOverloading.html

Só que estou me ferrando quando quero logar um inteiro primitivo por exemplo. Ele faz boxing e cria um Integer.

Para criar todos os métodos para tratar tudo que é combinacão de primitivos acho que passaria dos 100 mil. Alguém quer me ajudar fazendo um script que cospe isso?

Na verdade enquanto eu escrevia isso (EUREKA) veio a solucão. Tenho que transformar todo que é primitivo numa sequencia ASCII de bytes. Daí posso simplesmente traduzi-lo e passá-lo como um char[]. O MentaLog já tem um encoder que entende como logar char[] sem criar lixo. COOL!

O StringBuilder faz isso. Vou pegar de lá… Ou seja, ao invés de passar char[] posso passar um StringBuilder e tudo resolvido.

Debug.log(“number=”, to_sb(333));

Claro que isso é SINGLE-THREADED logo o meu StringBuilder retornado pode ser sempre o mesmo. (I love single-threaded nio)

saoj,

Eu vou te denunciar no the daily wtf também hehehehehe!!!

brincadeiras à parte, não daria para fazer nenhuma outra implementação? Nada dinâmico?

Edit: Pensando em 5 minutos, não me matem -> Não daria para, por exemplo, receber um array e desenrolar a coisa lá dentro do método?

jaboot:

brincadeiras à parte, não daria para fazer nenhuma outra implementação? Nada dinâmico?

Edit: Pensando em 5 minutos, não me matem -> Não daria para, por exemplo, receber um array e desenrolar a coisa lá dentro do método?

Pelo menos no meu caso eu fiz isso para simular o varargs (até 10 objetos) sem pagar o preco de criar um object array a cada chamada. Então eu passo um array interno cacheado para o varargs.

Parece que por tabela isso também reduz o tamanho do byte code.

@Override
	public void log(Object s1, Object s2, Object s3) {
		if (isSynchronized) {
			synchronized(this) {
				oa3[0] = s1;
				oa3[1] = s2;
				oa3[2] = s3;
				log(oa3);
			}
		} else {
			oa3[0] = s1;
			oa3[1] = s2;
			oa3[2] = s3;
			log(oa3);
		}
	}
	private Object[] oa3 = new Object[3];

Oi,

• So even though the class is ugly, there are good reason to have this in Groovy, even if the class makes
• absolutely no sense in normal Java. But it is not used in normal Java, but from the bytecode.

Tchauzin!