C# Command to Wait a Specified Period of Time

[Marc Gravell]

The difference is the query syntax guarantees binding tot he most

derived extension.

No it doesn't. There is no difference in this respect between the
query syntax ("from a in b where c select a") and the extension syntax
("b.Where(a=>c)"). They are identical. It is only the Expression vs
Func<> that makes a difference in terms of overload resolution. So
stick with the lambda and it is the same either way (it will select
Expression in both forms for *exactly* the same reasons).

Yes, it would be possible to be daft and throw a delegate into the
extension syntax, but a lot of daft things are possible if you try
hard enough...

Marc

 

[Marc Gravell]

it is easy to presume that you could extract that lambda out:

Func<Person,bool> f = p => p.Age < 20;
p.Where(f);

And there-in lies the bug. You *can* extract the lambda out, but you
need to tell it how:

Expression<Func<Person, bool>> f = p => p.Age < 20;

I'll agree that this is a mouthfull (and you can't cheat with "var").
However, now you can use it composably:

IQueryable<Person> source = null; // just checking compilier
here
var query1 = source.Where(f); // IQueryable<Person>

Marc

 

[Bill McCarthy]

hi Marc,

No it doesn't. There is no difference in this respect between the query
syntax ("from a in b where c select a") and the extension syntax
("b.Where(a=>c)"). They are identical. It is only the Expression vs Func<>
that makes a difference in terms of overload resolution. So stick with the
lambda and it is the same either way (it will select Expression in both
forms for *exactly* the same reasons).

Yes, it would be possible to be daft and throw a delegate into the
extension syntax, but a lot of daft things are possible if you try hard
enough...

Right so there is that possibility which means there is not the same
guarantee. Yes if you use lambdas in situ you don't have any difference,
but the difference is using extension methods does allow you to declare the
lambda outside of the method call, and hence change the binding. So as I
said, the query syntax *guarantees* the most derived binding where as the
extension method call does not. We're saying the same thing really, but
seem to disagree on what *guarantee* means

 

[Bill McCarthy]

Hi Marc,

And there-in lies the bug. You *can* extract the lambda out, but you need
to tell it how:

Expression<Func<Person, bool>> f = p => p.Age < 20;

Yep.



I'll agree that this is a mouthfull (and you can't cheat with "var").
However, now you can use it composably:

IQueryable<Person> source = null; // just checking compilier here
var query1 = source.Where(f); // IQueryable<Person>

Right. You could for example have a list of expressions and dynamically
interchange them. And this is something you cannot do with query syntax,
only extensions.

 

[Marc Gravell]

Re the guarantee - I think I see where you're coming from - but even
with a query expression, there is nothing to stop the programmer from
using a condition that can't be converted into a suitable query by the
provider, and no guarantee that the provider will be able to
mix-and-match via IEnumerable<T>. I don't think it can ever be truly
guaranteed either way - so I'd go with whichever solution a: works and
b: is clearest for maintenance. Sometimes IMO that would be query
syntax, and sometimes extension syntax.

Marc

 

[Bill McCarthy]

Re the guarantee - I think I see where you're coming from - but even with
a query expression, there is nothing to stop the programmer from using a
condition that can't be converted into a suitable query by the provider,
and no guarantee that the provider will be able to mix-and-match via
IEnumerable<T>. I don't think it can ever be truly guaranteed either way -
so I'd go with whichever solution a: works and b: is clearest for
maintenance. Sometimes IMO that would be query syntax, and sometimes
extension syntax.

Agreed The greatest difficulty is (a), determining what works, as that
does require runtime tests for queryable given the provider could be
changed.