In the normal implementations of C++, while not guaranteed by the standard, there is a vtable pointer as the header of every inherited class that needs a vtable pointer. There will be multiple vtable pointers for multiple inheritance that all have virtual functions.
In Java and C#, there is one s...
@mousetail there was a good quote about compilers vs databases, but i don't remember it
@mousetail linq is just not iterators. if the goal was only to have python list comprehension, they would have use list comprehension syntax.
linq's syntax looks a lot like sql and includes things like group by, order by... but the interesting point is that you can access and transform the linq expression into whatever you want... e.g. into sql
when it came out, there was hype about linq2sql and linq2xml (to query xml documents)... but if you ask me, the best part is that it also does list comprehensions :-)
That is not an uncommon perspective and there are quite a few “language with a database in it” attempts in one way or another
There was also Have you tried rubbing a database on it?, an online conference all about putting databases into things a couple of years ago that still has some interesting links
Something like Subtext is arguably a kind of database too
Yes, classic map functions work well for simple cases, especially compared to linq's heavyweight sql-inspired syntax. But complex linq queries are not so easily translated into functions form. They wouldn't look as good
Consider: from x in employees let tax = x.ComputeTax() orderby tax descending select x.LastName + ": " + tax
You'd have to do something like: employees .Select(x => new { x, tax = x.ComputeTax() }) .OrderByDescending(z => z.tax) .Select(z => z.x.LastName + ": " + z.tax)
Having to introduce tuple/records like that is a tax on readability that linq doesn't have to pay. Imagine with multiple let
