|
![](/i/fill.gif) |
Darren New wrote:
> But yeah, it's syntax sugar, like overloading operators is.
And if anyone cares, here's a fairly complex query written in LINQ, in C#
with extension methods, and in C# without extension methods.
http://www.interact-sw.co.uk/iangblog/2005/09/30/expressiontrees
about 3/4ths the way down, after the text "A little further into the demo"
Pretty cool. Especially since there's an Expression.Compile() instance
method that will generate actual CIL code for a parse tree you created at
runtime. (A la http://www.jot.fm/issues/issue_2008_03/column4.pdf ). But
AFAIK, once you've created CIL code, you can't unload it, at least not
without dumping the whole assembly context, so it winds up being a sort of
resource leak if you do this dynamically too much. I've seen libraries to
manage this, tho, starting with multiple assemblies and dumping them when
they get full, restarting with new ones. Seems kind of kludgey.
--
Darren New, San Diego CA, USA (PST)
"Ouch ouch ouch!"
"What's wrong? Noodles too hot?"
"No, I have Chopstick Tunnel Syndrome."
Post a reply to this message
|
![](/i/fill.gif) |