A
Arne Vajhøj
That is what the code does (even though I still prefer "execute
immediately" or "materializing" over "eager loading").
It does not change where the code is from.
Arne
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
That is what the code does (even though I still prefer "execute
immediately" or "materializing" over "eager loading").
It does not change where the code is from.
Arne
A
Arne Vajhøj
????
The fact that addons with second level cache exists seems to indicate
that it is not part of EF!
Arne
A
Arne Vajhøj
Please man you got an excuse for everything.
It is a very simple question: does EF come with second level
cache or not.
I can not see why it is an excuse to point out that the
second level cache you referred to does not come with EF.
Arne
A
Arne Vajhøj
Then how can NHibernate's ToList() return type be different from
Microsoft's? If it's exactly the same, then the return types should be
the same.
Exactly. That has been my point from the beginning.
Of course it is. Just reference NHiberate's library instead of .NET when
using IEnumerable extension methods.
I guess you could do that.
But not having System.Core.dll is going to hurt.
Arne
A
Arne Vajhøj
[...]
Well - I specifically stated "traditional NHibernate".
If you are going to jump into the middle of a conversation, it behooves
you to stick with the topic of the conversation.
I expect that people actually read what I write.
And it actually is on topic.
The topic of NHibernate and return types was brought up
without specifying whether it was traditional or LINQ
usage.
And given that they are somewhat different in this aspect
I considered it relevant to cover both.
[...]
Again: you will benefit from reading what I write. A little
back I wrote:
#In NHibernate LINQ a .ToList() returns an IList<T> (actually
#a List<T> that implements IList<T>, but ...).
Yes, you did write that. You wrote that the ToList() method returns >>>
IList<T> <<<. In NHibernate >>> LINQ <<<. Why you've got your panties in
a bunch of "traditional NHibernate" I have no idea. Even your own posts
at times wander back to the original topic at hand.
I was just explaining how traditional NH works and how NH LINQ
work to give a complete picture.
I assumed that readers would be able to comprehend two different
technologies in a single post.
How does it _not_ fit? The Microsoft ToList() returns List<T>. You wrote
that the NHibernate ToList() returns IList<T>. Not the same as Microsoft.
All of that is perfectly consistent with what I've written. What you're
writing now makes no sense at all. You're telling me I've got it wrong,
at the same time you're telling me I've got it right.
No - I am just trying something as advanced as explaining how the
two different API's to NH differ in ToList.
Arne
A
Arne Vajhøj
[...]
But it is possible to post actual code that show it returning
a IList<> (actually a List<> but I prefer the interface).
Your parenthetical comment is fundamental. It's exactly the opposite of
what you've written elsewhere, and is the key to the entire sub-topic
here. In particular, Enumerable.ToList<T>() does return List<T> as
you've written here, and NOT IList<T> as you wrote elsewhere.
In fact I also wrote that elsewhere.
You just seemed to consider the text a NOP.
Quite easily. Rather than bore you with all the gory details (other than
what I've written elsehwere), you might rather just read the work Jon
Skeet's been doing recently. First article in the series is here:
http://msmvps.com/blogs/jon_skeet/a...ting-linq-to-objects-part-1-introduction.aspx
It seems to be relative easy.
But note that Jon himself states "The purpose of all of this is
purely educational". He is not seeing this to be put in production.
Arne
A
Arne Vajhøj
[...]
And I find it a bit difficult to see how it could, because IEnumerable<>
ToList is in MS code not NHibernate code.
No, not necessarily. System.Linq.Enumerable.ToList<TSource>(this
IEnumerable<TSource> source) is MS code. But anyone can provide a
completely different extension method with the exact same signature and
use that instead.
There is no way to tell from a context-free snippet like this:
void SomeMethod<T>(IEnumerable<T> source)
{
IList<T> list = source.ToList();
}
…what the implementation of "source.ToList()" is. And even if we change
the type of the variable to "List<T>" instead of "IList<T>", at most we
can say (according to what you've written) is that it's not NHibernate
LINQ's implementation. But it still could be any other implementation,
not necessarily Microsoft's.
The only way to know the actual implementation is to see the entire
source file, so we can know what "using" directives are present
controlling which extensions methods are being used.
I guess he could be using a System.Core.dll replacement.
Or have been take Mono source, modified it and build it.
But the real issue was what NHibernate is doing.
And Hibernate is not doing anything funny.
It does not make much sense to complain about NH being
funky, if the reason behind the funkiness is that the
developer has replaced a part of .NET with something
not compatible.
Arne
A
Arne Vajhøj
On 12/27/10 1:36 PM, Arne Vajhøj wrote:
[...]
But it is possible to post actual code that show it returning
a IList<> (actually a List<> but I prefer the interface).
Your parenthetical comment is fundamental. It's exactly the opposite of
what you've written elsewhere, and is the key to the entire sub-topic
here. In particular, Enumerable.ToList<T>() does return List<T> as
you've written here, and NOT IList<T> as you wrote elsewhere.
In fact I also wrote that elsewhere.
No, you did not.
Actually I did.
In the post 13:43 EST.
And since you replied to it then you must have read it.
????
You wrote that the object's type was List<T>, but that
the method's return type itself was IList<T>. The former is true for
.NET's implementation of ToList<T>(), but the latter is not. And the
latter is the only thing relevant to this discussion.
An IList said:It's simply not relevant to the question of what the return type for the
method is. If you want to call it a "NOP", fine by me.
Since the statement matches MS's documentation, then I would consider
it very relevant to debunk your weird claim.
It is not particular relevant for the main topic.
So what? Just because Jon is not intending his project to be used in
production, that does not mean no one else would ever do such a thing,
and it certainly does not mean it's not feasible (never mind impossible,
as you've insinuated).
In a discussion about .NET and C# I would normally assume that
people do not replace .NET functionality with their own.
You can't say that much without making that assumption.
Arne
A
Arne Vajhøj
Yes. And you originally wrote that NHibernate LINQ's ToList<T>() method
has a return type of IList<T>. I quote: "In NHibernate LINQ a .ToList()
returns an IList<T>".
It does.
IList said:If it's returning type of IList<T> instead of List<T>, then it sure is
doing something funny.
IList<T> "is a" List<T>
It does both. And I already stated that a couple of times. You just seem
to ignore stuff in parenthesis's).
if NHibernate LINQ is in fact the component that has replaced a part of
.NET with something not compatible, then I'd say that's _exactly_ the
kind of reason one would complain about it "being funky".
But it is not.
So ...
Arne
A
Arne Vajhøj
Well, except that you are drawing false conclusions from the conditional
statement.
What conditional statement?
Arne
A
Arne Vajhøj
[...]How does it _not_ fit? The Microsoft ToList() returns List<T>. You wrote
that the NHibernate ToList() returns IList<T>. Not the same as
Microsoft.
And do you think that "actually a List<T> that implements IList<T>,
but ..." is a NOP in the English language?
????
What the heck is that supposed to mean? Just because the underlying
implementation of the interface is some known type, that doesn't make
the method's return value that type.
No.
And?
If the return type actually is a List<T> then it is surprisingly
a List said:According to your own posts, only one of the NHibernate APIs even
has/uses a ToList() method. So duh, of course they differ.
No. As was very clearly illustrated in one of my first posts,
then both API's can use .ToList().
More to the point, I still don't see how you can claim on the one hand
that NHibernate doesn't have its own LINQ ToList() implementation, and
yet on the other hand returns a different type from ToList() (i.e.
IList<T>) than the Microsoft implementation does (i.e. List<T>).
It doesn't.
Almost all my posts in this thread has been to explain that
NH LINQ does not use a different implementation.
Arne
A
Arne Vajhøj
On 12/27/2010 7:03 PM, Arne Vajhøj wrote:
<snipped>
<yawn>
Se ya I wouldn't want to be ya.
It is not that bad to know a little bit about
what is part of EF and what is not.
Arne
R
RayLopez99
Well, then should we go about saying that ToList() also returns a
System.Object? And an ICollection? And all those other things?
It does actually. And at the fundamental root of it all it's all just
ones and zeros.
Please, don't insult our intelligence. At this point, your semantic
quibbling is all about trying to defend a clearly incorrect statement,
by attempting to reframe its meaning contrary to what it obviously was
originally intended to mean.
Maybe, but he's a programmer. A good programmer can do that sort of
stuff. For example a master dev can use GOTO statements, global
variables (yes they exist even in .NET! I have done code that talks
to different assemblies and even different instantiations of the same
program, even if not on the same machine), unsafe pointers in managed
languages, disregard naming conventions and OOP, and other spaghetti
code techniques that us lesser mortals would trip on. So a good
developer can say "night is day and day is night" and get away with
it.
I think you two should kiss and make up, or at least shake hands since
we're not in San Francisco, since I find that both of you seem to know
what you are talking about. I sometimes lurk here and see the answers
you give people and lern things.
RL