É, parece que eu substimei o poder das “expressões lambda“, não que eu achasse que era um recurso ruim ou dispensável, mas cometi o erro gravíssimo de achar que esse recurso consistia apenas numa forma simplificada de se escrever um “delegate anônimo“, recurso que utilizo bastante, muito prático e deixa o código clean quando se precisa de algo simples e rápido.
Mas vocês sabiam que existe uma diferença nas duas linhas de codigo abaixo?
param1 => { return param1.someProperty == someValue; }
param1 => param1.someProperty == someValue
Ambas as linhas de código podem ser usadas como um método que recebe um parâmetro e retorna um valor booleano como resultado. E vocês podem estar se perguntando: “Se as duas podem ser usadas da mesma forma, então o que esse maluco está falando tanto em poder das lambda expressions?”, a resposta é simples e está debaixo do nasmepace System.Linq.Expressions, a primeira linha mostrada acima não pode virar uma Expression Tree, e o que isso quer dizer? Simples, uma Expression é uma classe que possui todas as informações disponíveis sobre a expressão que você montou, ou seja, olhando nós sabemos que a expressão exemplo do exemplo que dei é uma operação binária de igualdade senda aplicada sobre 2 operandos, o da esquerda (param1.someProperty) e o da direita (someValue). Vocês podem falar: “Tá, olhando é fácil deduzir isso, quero ver mostrar o código retornando essas informações”:
Expression<Func<SomeClass, Boolean>> a = param1 => param1.someProperty == someValue;
Console.WriteLine((a.Body as BinaryExpression).Left);
Console.WriteLine((a.Body as BinaryExpression).Method);
Console.WriteLine((a.Body as BinaryExpression).Right);
Com isso eu só deduzo uma coisa, esse recurso é EXTREMAMENTE flexível. É possível inventar basicamente o que quiser onde o uso de expressões sejam o forte, e com essas informações detalhadas sobre cada expressão é possível traduzir isso para qualquer outra coisa, não é à toa que o Linq é baseado nesse recurso das Expressions Trees, o Lambda torna o código muito sucinto e com todas as vantagens das checagens em compile time.
Agora fiquei eufórico de estudar isso a fundo e fazer um artigo sobre Expressions Trees, mas vou primeiro pesquisar na web para ver se já não tem muito material por aí, se eu achar que vale a pena fazer podem esperar.
Vou deixar só uma pergunta no ar: “Se de uma Lambda Expression é possível pegar a Expression Tree, o que vocês achariam de gerar um Lambda através de Expressões?”
Que isso mané? esse C# tá demais, só me surpreende…
2 comentários
Feed de comentários deste artigo
2009-07-22 às 23:30
Gustavo Rocha
Isso ai ainda é inteligente demais pra mim
2009-07-31 às 14:36
Jack
Cara, e isso só me faz rir. Lembro de você e o Picanço falando tanto que C# era garotice e eu só dizia “Estuda pra ver como que a coisa é, depois fala”. Hoje os dois mudaram de idéia, só não sei se o Picanço já admitiu isso rs.
A primeira vez que vi Lambda Expression foi no longínquo 2006, em uma palestra com um cara da MS Corp. Na hora não entendi direito, mas quando parei pra pesquisar, fiquei impressionado. Gosto do Python pela sua facilidade de manipulação, mas acho que ele perde um pouco do foco e se torna “maleável até demais”. Por ser prático demais, acaba deixando de ser prático, entende? Acho que esse tipo de recursos que o Linq trouxe, adicionou ao C# o nível certo de maleabilidade.
Sobre ExpressionTrees, escreva. Acho que é a coisa mais complicada que existe de se explicar no C# 3.0. Quando palestrei no lançamento do Visual Studio 2008, me preocupei em antes de explicar o C# 3.0, explicar o 2.0. Muita gente não entende expressão lambda por não ter a menor idéia da existência de um recurso simples como os métodos anônimos que eu sempre falei tanto e você deve se lembrar disso rs…