Linq "into" and "let" equally???

[Alexander Vasilevsky]

Linq "into" and "let" equally???

http://www.alvas.net - Audio tools for C# and VB.Net developers

[Jon Skeet [C# MVP]]

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail] twrote:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a *single* range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a *new* range variable. So,
for instance, you could do:

var query = from x in Enumerable.Rang e(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

it will fail, because at the "x+y" stage "x" is no longer available.

(I haven't tried the above code yet - I'm about to do so when I've
installed 3.5 onto my laptop.)

Jon

[Marc Gravell]

Sorry, what?

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail] twrote:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a single range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a new range variable. So,
for instance, you could do:

var query = from x in Enumerable.Rang e(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressionin to <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

On Nov 23, 9:27 am, "Frans Bouma [C# MVP]"
<perseus.usenet NOS...@xs4all.n lwrote:

But if you do:

var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressionin to <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

It's a good indicator that the only thing you care about from the
previous query is the actual result of the select - no intermediate
stuff needs to be propagated. (This could also make things a bit more
efficient in some cases, although that's rarely an issue.)

I'd personally write it as two queries:

var firstQuery = from x in source where blah select foo;
var secondQuery = from bar in firstQuery where ...;

which is basically the same thing, but a bit clearer IMO. There's room
for personal preference though :)

Jon

[Alexander Vasilevsky]

Thank You! Very good example!

http://www.alvas.net - Audio tools for C# and VB.Net developers
"Jon Skeet [C# MVP]" <sk***@pobox.co m???????/???????? ? ????????
?????????:
news:c0******** *************** ***********@o42 g2000hsc.google groups.com...

On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail] twrote:

>Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a *single* range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a *new* range variable. So,
for instance, you could do:

var query = from x in Enumerable.Rang e(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

it will fail, because at the "x+y" stage "x" is no longer available.

(I haven't tried the above code yet - I'm about to do so when I've
installed 3.5 onto my laptop.)

Jon

[Alexander Vasilevsky]

Why painful?

http://www.alvas.net - Audio tools for C# and VB.Net developers
"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l???????/???????? ?
???????? ?????????: news:xn******** *******@news.mi crosoft.com...

Jon Skeet [C# MVP] wrote:

>On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail] twrote:

Linq "into" and "let" equally???

Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?

I'll assume you mean "select ... into". They're not quite the same.
When you do "select ... into" you have a single range variable at
that point; any previous range variables are gone, basically.

If you do "let" then it just introduces a new range variable. So,
for instance, you could do:

var query = from x in Enumerable.Rang e(0, 10)
let y = x*2
select x+y;

But if you do:

var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone want
to use that construct in that way...

I mean: why would anyone use select <expressionin to <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Frans Bouma [C# MVP]]

Alexander Vasilevsky wrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with cursors
because they don't understand how set-oriented languages work.

FB

>

"Frans Bouma [C# MVP]" <pe************ ******@xs4all.n l>
???????/???????? ? ???????? ?????????:
news:xn******** *******@news.mi crosoft.com...

Jon Skeet [C# MVP] wrote:

>On Nov 23, 8:22 am, "Alexander Vasilevsky" <[e-mail] twrote:
Linq "into" and "let" equally???
>
Do you mean "do they do the same thing"? If so, do you mean
"select ... into" rather than "group ... into"?
>
I'll assume you mean "select ... into". They're not quite the
same. When you do "select ... into" you have a single range
variable at that point; any previous range variables are gone,
basically.
>
If you do "let" then it just introduces a new range variable. So,
for instance, you could do:
>
var query = from x in Enumerable.Rang e(0, 10)
let y = x*2
select x+y;
>
But if you do:
>
var query = from x in Enumerable.Rang e(0, 10)
select x*2 into y
select x+y;

With queries like that, I always wonder why on earth would anyone
want to use that construct in that way...

I mean: why would anyone use select <expressionin to <var? Or am I
the only one who finds the painful mix between set oriented
functionality and imperative programming within linq a bit 'odd' ?

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

[Jon Skeet [C# MVP]]

Frans Bouma [C# MVP] <pe************ ******@xs4all.n lwrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with cursors
because they don't understand how set-oriented languages work.

I don't see how it keeps people in an imperative mindset. It allows
them to express that the sequence which is the result of the "select"
is all they need for the next part of their query.

LINQ isn't actually set-oriented - it's sequence-oriented, a pipeline.
It may be convenient to think in terms of sets when writing LINQ to
SQL, but LINQ to Objects should *definitely* be considered in terms of
sequences.

--
Jon Skeet - <sk***@pobox.co m>
http://www.pobox.com/~skeet Blog: http://www.msmvps.com/jon.skeet
World class .NET training in the UK: http://iterativetraining.co.uk

[Frans Bouma [C# MVP]]

Jon Skeet [C# MVP] wrote:

Frans Bouma [C# MVP] <pe************ ******@xs4all.n lwrote:

Why painful?

because it keeps people in an imperative mindset, which means that
they can't use the set-oriented functionality in full potential.
Perfect examples are people who write long pieces of SQL with
cursors because they don't understand how set-oriented languages
work.

I don't see how it keeps people in an imperative mindset. It allows
them to express that the sequence which is the result of the "select"
is all they need for the next part of their query.

LINQ isn't actually set-oriented - it's sequence-oriented, a
pipeline. It may be convenient to think in terms of sets when
writing LINQ to SQL, but LINQ to Objects should definitely be
considered in terms of sequences.

A query which is executed on a db, will end up as a set-oriented
statement. If you write your query as imperative as possible, you WILL
probably have a slow query. A query written to be executed on a DB
should be written with set operations in mind, otherwise you will end
up sooner or later at the wrong end of the DBA-developer conversation
where you need to optimize the query to make it performing properly but
you don't know how.

FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------