C#2 mais tranqueira para a Sun correr atras?

Assuntos Gerais
#1

Deem uma olhada nesse documento:
http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/SpecificationVer2.doc

Resumo:

C#2 vem com suporte a:

-Generics, de forma bem mais abrangente e poderosa que a versao java

-Anonimous functions, suporte a definir funcoes no lugar onde um delegate eh esperado

-Iterators, funcionam como os generators do python, uma ideia bem legal, basicamente 1 implementacao mutilada de continuations.

-Partial types, poder definir suas classes em multiplos arquivos.

Pessoalmente gostaria de ver suporte mais completo de generics em java, mas longe da locura do c++.
Funcoes anonimas so faria sentido se java tivesse suporte a referencia para funcoes, outra coisa que seria uma maravilha.
Iterators da forma como estao implementados no C#2 acho que nao valem a pena, exigiria uma mudanca enorme na JVM para um recurso proposto de forma limitada.

Partial types seria A grande burrada, isso estimularia a criacao de muito lixo. Vide as anti-patterns de blob e swiss army knife. “na nossa aplicacao, cada desenvolvedor modifica a classe XXX no seu proprio arquivo, funciona errr, bem! Mas so as vezes, quando faz calor aqui na siberia”

#2

[list]concordo que partial types seria absurdo :-)[/list]
[list]metodos anonimos são praticamente a mesma coisa que uma classe anonima se você trabalhar com adapter junto :-)[/list]
[list]os generics não vi diferença menhuma, as collections em java ja virão utilizando generics, mas você pode criar qualquer classe generica[/list]

a parte dos iterators eu não entendi muito bem :slight_smile:

#3

[quote=“urubatan”][list]concordo que partial types seria absurdo :-)[/list]
[/quote]
A unica utilidade eh para separar a interface publica da sua classe da implementacao.
Voce colocaria todas parte publica da classe em 1 arquivo e o resto, inclusive a implementacao
da parte publica em outro, bem ao estilo do c++.
O problema disso eh complicar muito pro compilador. Nao quero meu projeto levamos horas para compilar.

Tao mais para 1 subconjunto de classes anonimas, porem eu mesmo falei, so fazem sentido se tivessemos suporte a referencia para funcoes.

Existem varias diferencas:

[list]Voce pode especializar com um tipo primitivo, com java voce nao podera ter List<int[/list]
[list]Existem alguns contrains a mais disponiveis, como poder dizer que a classe deve ter um contrutor vazio [/list]

[quote]
a parte dos iterators eu não entendi muito bem :-)[/quote]

Iterators/Generator, ou continuations na forma generica, sao mais faceis de como se fossem algo proximo de outra thread, onde existe uma forma facil para comunicacar uma com a outra.

Para o cado de Iterators nao tem muito segredo.

Um iterator no java tem que guardar todo seu estado em variaveis locais de forma que entre uma chamada e outra do next() ele tem como continuar.

Porem com continuations voce pode programar seu Iterator de forma linear, como 1 simples funcao:

class ArrayIterator  {
...
  Object[] array = ...;

  Object next() {
       for(int i = 0; i < array.length; ++i)
            yield array[i];
       yield break;
  }
}

Quando voce chamar o next() pela primeira vez sera criado um contexto separado onde o next() sera executado.
Sempre que durante um next() ocorrer o yield xx, ele para de executar e retorna esse objeto para quem invocou ele.
Agora, na proxima vez que next() for chamado, a funcao volta de onde ela parou.

por exemplo:

class OutroIterator  {
  String next() {
     yield "1";
     yield "2";
     yield "3";
     yield break;
  }
}
....
void main() {
OutroIterator o = new OutroIterator();
System.out.println(o.next());
System.out.println(o.next());
System.out.println(o.next());
}

A saida aqui vai ser:

Loco ne? Super util isso, porem na forma que esta proposta no C#2 eh muito fraquinha, tinha que ser 1 esquema feito o call/cc do scheme

#4

bom, utilizando generics+box/unbox tu vai poder ter uma List ou bem proximo disto :slight_smile:

o esquema do iterator dele é bem legal mesmo, muito mais facil de construir um iterator do que em java, mas perde algumas funções, acho que pouco utilizadas, mas disponiveis, como o remove do iterator do java :slight_smile:

mas gostei da ideia deles :slight_smile:

ja quanto ao partial class, acho que seria terrivel isto, ja que esta é a parte que menos gosto do c++ :slight_smile:

enfim, algumas ideias deles são realmente muito boas, e a competição é sempre bem vinda e saudavel para ambos os lados :slight_smile:

#5

Oi Louds. Nao esta implementado ainda, mas voce vai pode ter sim uma List<tipoprimitvo> por causa do autoboxing e unboxing. Soh se eles tiraram do JSR final, tiraram?

#6

Sim, voce pode ter ainda 1 List e trabalhar razoavelmente bem com autoboxing (auto un-boxing nao existe na 1.5)
ou seja:

List<Integer> list = new ArrayList<Integer>();
list.add(1);
list.add(2);
int um = list.get(0).intValue();
int dois = list.get(1).intValue();

Solucao muito melhor que hoje onde usamos 1 tonelada de casts.
Mas isso tem um problema, a performance eh horrivel. Toneladas de objetos descartaveis sendo constantemente alocados fazem teu programa gastar ate 40% do seu tempo no gc e isso eu tou vendo diante dos meu proprios olhos usando BigInteger. E pior ainda, ela esconde boa parte do sintoma antras de auto-boxing!

urubatan, remove() funciona sem problemas nesse esquema de Iterators do C#2, da ate menos trabalho pra implementar quanto seria sem.

#7

louds, dizem que eles vao otimizar isso
isto eh, uma list de integers nao vai ser tratada dessa forma. mas tem de ver neh?

#8

[quote=“Paulo Silveira”]louds, dizem que eles vao otimizar isso
isto eh, uma list de integers nao vai ser tratada dessa forma. mas tem de ver neh?[/quote]

Os caras vão tem 1 senhor trabalhão para fazer isso Paulo. Imagina 1 pouco o seguinte pedaço de código:

class X<T>{
void find(T t) {
  synchronized(t) {
      int h = t.hashCode();
      ....
  }
}
}

O grande problema para suportar generics para tipos primitivos é que eles são diferentes de Objetos, logo em muito dos casos não daria para escrever uma Generic class que funcionasse com ambas.

Ou então imagina outro exemplo:

class Y<T>  {
   T create() {
      return new T();
   }
}
#9

[quote=“louds”]Sim, voce pode ter ainda 1 List<Integer> e trabalhar razoavelmente bem com autoboxing (auto un-boxing nao existe na 1.5)
[/quote]

oi louds
fui la visitar a jsr.
tem unboxing sim!

#10

tem?
ate a última vez que eu tinha olhado só tinha autoboxing porque unboxing representa 1 enorme problema:

int i = (Integer)null;

e ai? da null pointer?

#11

pelo JSR
int i = (Integer)null;

da zero :slight_smile:

foi uma discussão bonita até eles decidirem o que iria acontecer neste caso :slight_smile:

#12

http://jcp.org/aboutJava/communityprocess/jsr/tiger/autoboxing.html

There is no permitted conversion from the null type to any primitive type.
There is no permitted conversion to the null type other than the identity conversion.

#13

agora fiquei confuso
convesão de null para primitivos vai dar 1 ClassCastException então?

#14