Keith J. Farmer wrote:
> I've had no problems with not grandfathering in older APIs, and am quite 
> happy to not grandfather in older syntax, either.
>   

What do you mean by 'grandfathering' in this context?

Michael

>  
> I agree that IronPython would have to be able to distinguish between CLR 
> attributes and Python decorators, inasmuch as CLR attributes are a static 
> part of the class/member definition.  But I don't think it's an 
> insurmountable problem, and solving it in the DLR, actually, would be very 
> useful.
>  
> I wouldn't expect that class authors would want to change the set of .NET 
> attributes frequently if at all -- it doesn't match how they've been designed 
> and how they've evolved, so creating the attributed base class once (and then 
> having pythonic decorators coming in and out at will) seems like a reasonable 
> approach to me.
>
> ________________________________
>
> From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
> Sent: Mon 2/4/2008 11:13 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] Decorators on classes
>
>
> Oh! I didn't realize that about 2.6.
>  
> There is indeed a big difference between a Python runtime decorator and a 
> .NET compile time attribute; in fact, the similarities are superficial at 
> best.
>  
> .NET attributes are totally static, so there's no way to modify a .NET class 
> definition to add them.  The IronPython engine would have to recognize 
> particular class-level Pythonic annotations and use that information to emit 
> a new CLR class to represent the Python class.  It already emits CLR classes 
> as needed to represent Python classes.  By "as needed", I mean that a 
> specific CLR base class plus a specific set of CLR interfaces will uniquely 
> determine a class to be emitted by IronPython.  This class is cached so that 
> -- once generated -- any new Python class definition that matches this set of 
> (CLR base class plus interfaces) will reuse the same CLR class definition.
>  
> What you'd have to change is to put the class-level attributes onto the 
> generated CLR class, then change caching so that the key is (CLR base class 
> plus interfaces plus attributes).  It's definitely doable, but raises 
> intriguing questions about "purity".  And you'd also need to consider the 
> impact on the larger DLR.
>
> Method-level attributes are an entirely different matter.
>
> On Feb 4, 2008 10:58 AM, Michael Foord <[EMAIL PROTECTED]> wrote:
>
>
>       Class decorators will be in Python 2.6 - but there is a big difference
>       between a Python runtime decorator and .NET compile time attributes. Is
>       it possible to attach attributes at runtime using the reflection API?
>       
>       Michael
>       http://www.manning.com/foord
>       
>
>       Keith J. Farmer wrote:
>       > Can I resurrect this forgotten soul?  
> http://www.codeplex.com/WorkItem/View.aspx?ProjectName=IronPython&WorkItemId=13583
>       >
>       > Having just finished working on LINQ to SQL, I'm convinced that 
> future LINQ providers will be making heavy use of .NET attributes not just on 
> properties, but on classes themselves.  Being able to express these 
> attributes in IronPython is a tremendous bonus.  That there be one and only 
> one way to express these is paramount.
>       >
>       > _______________________________________________
>       > Users mailing list
>       > Users@lists.ironpython.com
>       > http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>       >
>       >
>       
>       _______________________________________________
>       Users mailing list
>       Users@lists.ironpython.com
>       http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>       
>
>
> _______________________________________________
> Users mailing list
> Users@lists.ironpython.com
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>   

_______________________________________________
Users mailing list
Users@lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com

Reply via email to