- Possiveis funcionalidades do C# 6.0
- “Primary constructors”
- Propriedades (automaticas) somente leitura
- “Using” para membros estáticos
- Property Expressions (não sei nem como traduzir isso)
- “Method expressions”
- Enumerables como parâmetros do tipo “params”
- Checagem de “null” mais inteligente (ou “monadic null checking”, o que quer que isso queira dizer ;)
- Inferência de tipos a partir de parêmtros de construtores
- Declaração inline para parâmetros out
- Compilador como serviço
- Funcionalidades que gostaria de ver na próxima versão do C#
Possiveis funcionalidades do C# 6.0
Sei que alguns desenvolvedores verão este post como notícia velha, mas eu me deparei com estas informaçoes hoje e as achei bem interessantes e acredito que estas podem ser úteis a mais desenvolvedores (mesmo porque não encontrei muito sobre o assunto em português), assim sendo, decidi postar sobre o assunto.
Se você deseja ver os posts originais (em inglês) veja estes links (ambos são baseados em um evento da Microsoft chamado NDC que ocorreu em Londres Dez/2013).
Os comentários representam a minha opnião (que pode não representar nada para você :)) e eu não sou, de forma alguma, um especialista em linguagens de programação (por exemplo não fiz esforço algum para verificar se as minhas sugestões não introduziriam ambiguidades na sintaxe da linguagem).
“Primary constructors”
class Exemplo
{
public Exemplo (int valor, string nome)
{
this.valor = valor;
this.nome = nome;
}
private int valor;
private string nome;
}
class Exemplo (int valor, string nome)
{
private int valor;
private string nome;
}Os seguintes pontos não ficaram claros para mim:
- será possível ter um corpo no construtor ?
- paramêtros com valor default (possivelmente sim) ?
- qual a visibilidade deste construtor? Assume a visibilidade da classe ?
- será possivel definir outros construtores ?
Já que o objetivo é simplificar porque não introduzir um conceito tipo “campos automáticos” ou mesmo “propriedades automáticas” permitindo assim reescrever o exemplo como:
class Exemplo (int valor, string nome) // Isto definiria os campos valor e nome.
{
}Propriedades (automaticas) somente leitura
class Exemplo
{
public int PropriedadeSomenteLeitura { get; private set; }
}class Exemplo
{
public int PropriedadeSomenteLeitura { get; } = um_campo_qualquer * UmMethodQualquer(1.0);
}Eu realmente não vejo muito ganho com isto. Prefiro a versão abaixo (já suportada atualment é claro)
(ok, eu sei que as mesmas não são semanticamente equivalentes, mas param mim, isto já é o suficiente)
class Exemplo
{
public int PropriedadeSomenteLeitura { get; private set; }
}Outra questão é: o que pode ser usado como valor da propriedade? Qualquer expressão? Por exemplo, o código abaixo é válido?
class Exemplo
{
public int PropriedadeSomenteLeitura { get; } = um_campo_qualquer * UmMethodQualquer(1.0);
}“Using” para membros estáticos
class Exemplo
{
public double M()
{
return System.Math.Sqrt(1.0, 4.2);
}
}using System.Math;
class Exemplo
{
public double M()
{
return Sqrt(1.0, 4.2);
}
}Sério? Java já suporta este recurso a algum tempo… e eu nunca gostei muito do mesmo… ;)
Property Expressions (não sei nem como traduzir isso)
class Exemplo
{
public decimal ValorTotal { get { return Quantidade * ValorUnitario ; } }
}
class Exemplo
{
public decimal ValorTotal => Quantidade * ValorUnitario;
}Na minha opnião vivemos muito bem sem este recurso.
Péssimo nome (talvez Property Shortcut seria um nome mais descritivo)
“Method expressions”
class Exemplo1
{
public Point Move(int dx, int dy)
{
return new Point(X + dx, Y + dy);
}
}class Exemplo1
{
public Point Move(int dx, int dy) => new Point(X + dx, Y + dy);
}Mesma coisa que “property expressions”
Enumerables como parâmetros do tipo “params”
class Exemplo
{
public void FazAlgo(params []MeuTipo items) { }
}class Exemplo
{
public void FazAlgo(params IEnumerable<MeuTipo> items) { }
}Sem dúvida alguma, qualquer desenvolvedor que já tenha escrito métodos usando número de parâmetros variáveis (identificado pela palavra reservada params) sabe o quanto o mesmo é útil. Suportar IEnumerable<T> além de arrays torna os mesmos muito mais versáteis (pode-se passar qualquer coleção padrão!)
Dessa eu gostei pois não me obriga criar arrays só para poder chamar métodos como no exemplo acima (lembre-se que em C# arrays implementam IEnumerable<T> então, passar arrays, para métodos definidos como o exemplo acima, não exige conversões!
Checagem de “null” mais inteligente (ou “monadic null checking”, o que quer que isso queira dizer ;)
class Exemplo
{
public int M(IList<string> ss)
{
if (ss != null)
{
var primeiraOuNulo = ss.FirstOrDefault();
if (primeiraOuNulo != null)
return primeiraOuNulo.Length;
}
return -1;
}
}class Exemplo1
{
public int M(IList<string> ss)
{
return ss?.FirstOrDefault()?.Length ?? -1;
}
}
Vamos acabar com o Natal! (afinal de contas, este tipo de sintaxe ajudaria em muito a por um fim em código tipo arvore de natal). Eu conheço alguns desenvolvedores que ficaram muito desapontados se este recurso for realmente incorporado à linguagem - já posso ver os argumentos de que agora o código esta mais complexo, não é trivial ;)
Ponto para a equipe do C#.
Inferência de tipos a partir de parêmtros de construtores
void M()
{
var l = new List<string> { "Lista", "de", "strings" };
}void M()
{
var l = new List { "Lista", "de", "strings" };
}Preciso dizer algo? Se você já desenvolveu aplicativos em C# com um nível de complexidade acima do trivial sabe o quanto é tedioso ficar lembrando o compilador sobre informações que ele já tem (ou que poderia facilmente obter). Mais um ponto para os designers da linguagem.
Alguns vão dizer que a linguágem X ou Y é muito melhor no quesito inferência de tipos; pode até ser verdade, mas eu uso o C# no dia-a-dia, não estas linguaguens ;), assim sendo, melhorias no sistema de inferência de tipos são bem vindas.
Declaração inline para parâmetros out
void M()
{
int valor;
if(Int32.TryParse("42", out valor))
return valor;
return -1;
}void M()
{
return Int32.TryParse("42", out int valor) ? valor : -1;
}Hum.. este recurso me deixou em dúvida; embora eu entenda que esta mudança tem o potencial de diminuir a quantidade de código em certas construções comuns em programas (métodos no estilo TryParseXXXX() me vem a cabeça imediatamente) ainda receio que o ganho proporcionado seja menor que o risco de mau uso.
Compilador como serviço
De acordo com Anders Hejlsberg (neste vídeo +- 00:34), é possível que o projeto conhecido como Roslyn também seja liberado na próxima versão do Visual Studio! Se você ainda não deu uma olhada no mesmo, eu recomendo dedicar alguns minutos (possivelmente algumas horas :)) para fazê-lo! Outra solução semelhante é o NRefactory.
Agora que já discuti as possíveis funcionalidades da próxima versão do C# (pelo menos, segundo os posts que eu encontrei), gostaria de expor minha lista de desejos pessoal.
Funcionalidades que gostaria de ver na próxima versão do C#
Classes anônimas implementando interfaces
Se você já desenvolveu em Java provavelmente já fez uso deste recurso e possivelmente sabe o potencial para diminuir a quantidade de código escrito bem com simplificá-lo. Sinceramente, este é uma das poucas funcionalidades de Java que eu sinto falta no C#. Se você não tem idéia do que estou falando veja o exemplo abaixo:
public interface IFoo
{
void DoIt();
string Name { get; }
}
class Exemplo
{
public void FazAlgo()
{
var itfImpl = new IFoo
{
void DoIt() { }
string Name { get { return "name"; } }
}
System.Console.WriteLine(itfImpl.Name);
}
}Em uma versão hipotética do C#, nas linhas 12 ~ 17 implementamos a interface IFoo anonimamente (ou seja, sem a necessidade de definir uma classe explicitamente).
Extension properties
Da mesma forma que extension methods podem simplificar, e muito, algums cenários de programação, acredito que o mesmo conceito aplicado à proriedades seria bastante útil (pelo menos eu já me deparei com algumas cituações onde o mesmo seria realmente muito bem vindo).
static class StringExtensions
{
public static extension bool ContemAdriano
{
get
{
return value.Contains("Adriano"); // value representa a string.
// Em nosso exemplo de chamada
// value representa o parâmetro 's'
}
}
}
class Exemplo
{
public bool FazAlgo(string s)
{
return s.ContemAdriano;
}
}Interpolação de strings
Interpolação de strings permite a substituição de uma (ou mais) parte(s) de uma string pelo valor de uma variável de uma forma simples e intuitiva. Abaixo apresento um exemplo hipotético caso o conceito fosse suportado em C#:
class Exemplo
{
public void FazAlgo()
{
int valor = 10;
System.Console.WriteLine("Valor = $valor, Nome= $nome");
}
public string nome;
}O mesmo exemplo, hoje, pode ser escrito como:
class Exemplo
{
public void FazAlgo()
{
int valor = 10;
System.Console.WriteLine("Valor = {0}, Nome={1}", valor, nome);
}
public string nome;
}Apesar de algumas reservas, devido ao potencial de confusão em casos onde strings referenciem variáveis declaradas em um escopo distante, gostaria de ver esta funcionalidade na próxima versão do C#!
Modernização de algumas APIs da FCL
Ok, este ponto não tem nada a ver com a linguagem C# propriamente dita, mas já que estou reclamando, não custa nada incluir mais um item na lista de reclamações ;)
Eu admito: eu amo LINQ, e estou certo de que você, caso desenvolva aplicativos de tamanho razoável, também aprecia a elegância desta tecnologia; contudo, muitas das APIs da FCL não estão otimizadas para uso com LINQ. Um exemplo é a classe Regex e relaciondas (recentemente tenho usado as mesmas com bastante frequência); com mais frequencia do que eu gostaria eu me vejo escrevendo cógido como o exemplo abaixo:
var r = Regex.Matches("07/11/1990", "(?<componente>\d{2,4})+");
r.Groups.OfType<Group>().Where(...);só porque a propriedade Groups é declarada como GroupCollection ao invés de IEnumerable<Group> ou algo parecido. Este é apenas um exemplo; existem muitas outras APIs que se beneficiariam se fossem refatoradas com LINQ em mente.
Antes que alguém reclame e me diga que eu posso implementar os operadores LINQ mais comuns esperando GroupCollection como parâmetro ao invés de IEnumerable<Group> gostaria de lembrá-lo que este é apenas um dos casos; só na família de classes relacionadas à regular expressions temos GroupCollection, CaptureCollection e MatchCollection; existe uma boa probabilidade de seu código depender de outras APIs da FCL que implementão coleções não padrão e, se isso ocorre, você terá que implementar operadores LINQ para elas também.
O que você acha de tudo isso? Quais funcionalidades você gostaria de ver implementadadas na próxima versão da linguágem?
Boa programação!
