lambn

[Mike P]

I've just been reading up on lambda expressions and how you can use them
to make selections from XML in a similar syntax to SQL. Does this mean
no more need for Xpath? I have used Xpath once or twice and hate the
syntax, and I would be delighted if I could use lambda expressions
instead when Orcas is released.

 

[Kevin Spencer]

I believe you're referring to LINQ
(http://msdn2.microsoft.com/en-us/library/aa479865.aspx#linqprojec_topic7)
rather than Lambda Expressions. As for not needing XPath, you would still
need XPath syntax for, for example, XSLT. LINQ is a language that attempts
to unify syntax for querying various aggregate types including XML in
managed programming. I think it is a great idea.

Lambda expressions are a way of more concisely coding certain types of
statements. Personally, I have some reservations about Lambda expressions,
as they do not compile any more compactly than the clearer (more
human-readable) syntax already available. I am worried that C# is being
exposed to a vulnerability that exists in the C language, which enables
developers to write code that is entirely too cryptic to serve the purpose
of productivity.

I have the same reservations about implicit types. In fact, I really don't
get implicit types, since you have to "declare the type" as "var." That is,
the variable declaration is not more concise, but it is more confusing.

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Nicholas Paldino [.NET/C# MVP]]

See inline:

I believe you're referring to LINQ
(http://msdn2.microsoft.com/en-us/library/aa479865.aspx#linqprojec_topic7)
rather than Lambda Expressions. As for not needing XPath, you would still
need XPath syntax for, for example, XSLT. LINQ is a language that attempts
to unify syntax for querying various aggregate types including XML in
managed programming. I think it is a great idea.

Lambda expressions are a way of more concisely coding certain types of
statements. Personally, I have some reservations about Lambda expressions,
as they do not compile any more compactly than the clearer (more
human-readable) syntax already available. I am worried that C# is being
exposed to a vulnerability that exists in the C language, which enables
developers to write code that is entirely too cryptic to serve the purpose
of productivity.

Lambda expressions have two purposes. One, as you mentioned, they are a
concise way of expressing code expressions, which are a fundamental part of
how LINQ works. When the language-specific extensions for LINQ are
transformed into the extension method calls on IEnumerable<T> (which are
really transformed into static method calls), these expressions are passed
in order to perform things like filtering and projections.

Lambda expressions have a much deeper purpose though which becomes more
apparent when using LINQ for SQL and LINQ for XML. Lambda expressions are
not completely compiles, but rather, transformed into an expression tree.
When running LINQ over objects, this expression tree is compiled by the CLR
into executable code. However, when using something like LINQ to SQL, or
LINQ to XML, those expression trees are evaluated in order to help generate
the query syntax that is native to the underlying data source (T-SQL or
XPath, for example).

I have the same reservations about implicit types. In fact, I really don't
get implicit types, since you have to "declare the type" as "var." That
is, the variable declaration is not more concise, but it is more
confusing.

The whole reason that you need implicit typing is because of the fact
that you can create projections using link. In other words, if you have a
class that has five properties, you can select two of those properties into
a new anonymous type. Because link returns IEnumerable<T>, and you don't
know what T is because of the projection, you need something like implicit
typing to handle the return type.

Of course, this feature can lead to abuse. The good thing though is
that it is not like a variant, or object (I'm sure you know, but in case
someone else reading this does not) where the compiler can not enforce type
safety.

 

[Kevin Spencer]

Thanks for the clarification, Nicholas. That makes it all perfectly logical!

--

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

See inline:

I believe you're referring to LINQ
(http://msdn2.microsoft.com/en-us/library/aa479865.aspx#linqprojec_topic7)
rather than Lambda Expressions. As for not needing XPath, you would still
need XPath syntax for, for example, XSLT. LINQ is a language that attempts
to unify syntax for querying various aggregate types including XML in
managed programming. I think it is a great idea.

Lambda expressions are a way of more concisely coding certain types of
statements. Personally, I have some reservations about Lambda
expressions, as they do not compile any more compactly than the clearer
(more human-readable) syntax already available. I am worried that C# is
being exposed to a vulnerability that exists in the C language, which
enables developers to write code that is entirely too cryptic to serve
the purpose of productivity.

Lambda expressions have two purposes. One, as you mentioned, they are
a concise way of expressing code expressions, which are a fundamental part
of how LINQ works. When the language-specific extensions for LINQ are
transformed into the extension method calls on IEnumerable<T> (which are
really transformed into static method calls), these expressions are passed
in order to perform things like filtering and projections.

Lambda expressions have a much deeper purpose though which becomes more
apparent when using LINQ for SQL and LINQ for XML. Lambda expressions are
not completely compiles, but rather, transformed into an expression tree.
When running LINQ over objects, this expression tree is compiled by the
CLR into executable code. However, when using something like LINQ to SQL,
or LINQ to XML, those expression trees are evaluated in order to help
generate the query syntax that is native to the underlying data source
(T-SQL or XPath, for example).

I have the same reservations about implicit types. In fact, I really
don't get implicit types, since you have to "declare the type" as "var."
That is, the variable declaration is not more concise, but it is more
confusing.

The whole reason that you need implicit typing is because of the fact
that you can create projections using link. In other words, if you have a
class that has five properties, you can select two of those properties
into a new anonymous type. Because link returns IEnumerable<T>, and you
don't know what T is because of the projection, you need something like
implicit typing to handle the return type.

Of course, this feature can lead to abuse. The good thing though is
that it is not like a variant, or object (I'm sure you know, but in case
someone else reading this does not) where the compiler can not enforce
type safety.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

--
HTH,

Kevin Spencer
Microsoft MVP

Printing Components, Email Components,
FTP Client Classes, Enhanced Data Controls, much more.
DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net