Right.. it's just a pattern for metaprogramming. The current implementation just has a little bit of compiler assist. There are the underlying extension methods (which are defined in a very Pythonic way: static Foo Bar(this Baz, Gleep)), which can be used directly, or wrapped in sugar. Of course, you don't *have* to have extension methods -- they just allow for mix-ins (more Python) so we can avoid writing the same code for every IEnumerable<> in the system. I think the interesting bit for us, now, is that all this runs on the 2.0 runtime. From what I can tell, all it'd take would be some compiler modifications to recognize extension methods (marked by attribute) and to create an easy way to create expression trees, and IronPython would be set for it. Yes, I'm excited about LINQ.. I've seen many gems come out of .NET (and a few blunders). This, I think, is just plain beautiful.
________________________________ From: [EMAIL PROTECTED] on behalf of Michael Latta Sent: Tue 9/20/2005 9:47 AM To: 'Discussion of IronPython'; [EMAIL PROTECTED] Subject: RE: [IronPython] Extension methods... Keith, Your summary of LINQ is correct in technical details. I believe that the comment was about preferred syntax. The same could be done for Python, by allowing the list comprehension syntax to be used to produce expression trees not just executable blocks. This was the main thing I liked about LINQ. The language features to support it were not custom to that usage, but could be used in other contexts. Defining what Python specific compiler/language features would yield the same flexibility is what caught my attention. At the run-time level interop would be useful, but at the syntax level something that is more "Pythonish" would be nice. _______________________________________________ users-ironpython.com mailing list users-ironpython.com@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
