[IronPython] Extension methods...

Keith J. Farmer kfarmer at thuban.org
Tue Sep 20 10:33:51 PDT 2005


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: users-ironpython.com-bounces at lists.ironpython.com on behalf of Michael Latta
Sent: Tue 9/20/2005 9:47 AM
To: 'Discussion of IronPython'; thane at magna-capital.com
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.





More information about the users-ironpython.com mailing list