[IronPython] CLS compilation
I am changing the subject to better reflect the discussion. I have posted a
blog at
http://blogs.msdn.com/shrib/archive/2008/07/24/cls-compilation-of-ironpython.aspx
discussing some issues I see.
Keith, as far as exposing IronPython types as System.Type, its not just a
question of inheriting from System.Type. If we did just that, the resulting
Type would not be usable from important APIs like Activator.CreateInstance,
from IL instructions like newobj, etc. because the CLR has special knowledge
about the System.Type object it creates from metadata.
Also, LINQ to SQL does look like an interesting scenario. I mention this at the
end of the blog. However, the reason to collect real use cases is to know
exactly what features are needed. Supporting the full range of CLS features may
not be necessary. Knowing how folks are wanting to use the feature can guide
the design of the feature in the future. For example LINQ to SQL only needs
CustomAttributes on types but not on methods AFAIK. This may could make a
significant difference as support CustomAttributes on method is much more
complicated.
So do send in other use cases you have run into...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland
Sent: Wednesday, July 23, 2008 7:41 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
The only problem w/ the existing Type and MemberInfo classes is that they all
require inheritance demands to inherit from them. That prevents us from
subclassing them in anything core because it won't work in Silverlight or other
partial trust scenarios. But it is something we've been working w/ the CLR
team on getting fixed so we'll be able to take that approach in the future -
there's other areas where it'd be useful as well.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer
Sent: Wednesday, July 23, 2008 7:30 PM
To: Discussion of IronPython; Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
I can answer both in one: To be able to use IronPython to create data classes,
marked up with attributes, to be consumed by APIs probably written in something
other than IronPython.
That's it.. quite simple.
Example of such an API: LINQ to SQL. Or LINQ to whatever, since outside of of
Objects and XML, things pretty much end up with mapping metadata and attributes
are one of the first places to look for that.
And so, in light of the DLR effort, and the general push to make the static
languages be able to work well with the dynamics, I think it's only right that
the DLR languages be able to expose their dynamic types in such as way as to be
transparent to the static languages. That's why I pointed out that Type is an
abstract class and the MemberInfo subclasses themselves appear to be
subclassable. It really appears that the API is there, waiting to be
implemented.
Otherwise, really, the dynamic languages are completely unusable for certain
APIs -- they just don't interact with the reflection API in such a way that
libraries can consume in a reasonable, language-neutral manner.
From: [EMAIL PROTECTED] on behalf of Curt Hagenlocher
Sent: Wed 7/23/2008 4:39 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
So, we had a brief hallway discussion today about this topic, and the upshot is
that I'm interested in hearing your real world use cases for
a) attributes, and
b) static type generation in general
By use case, I mean a scenario that's specifically relevant to you today. By
relevant, I mean that it would be *nice* to be able to write a PowerShell
extension in Python, but if you didn't end up writing the extension in another
language, then it doesn't really count for what I'm looking for. :)
On Mon, Jul 21, 2008 at 4:16 PM, Keith J. Farmer [EMAIL
PROTECTED]mailto:[EMAIL PROTECTED] wrote:
We are talking about *new* features, but you're limiting yourself to existing
APIs?
If, for the sake of working nicely with the DLR, the existing reflection API
needs to be modified to deal with a more dynamic world, that's not outside the
realm of possibility in my books. After all, there has always been talk of IP
being able to expose static types for consumption outside of IP. I don't see
that this is any less possible now than it was at the start.
Incidentally, Type is an abstract class. Also, ParameterInfo isn't sealed, and
implements ICustomerAttributeProvider, which is a public interface:
public interface ICustomAttributeProvider
http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Reflection.ICustomAttributeProvider
{
// Methods
object
http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:2.0.0.0:b77a5c561934e089/System.Object
[] GetCustomAttributes
[IronPython] Switching Mailing List to CodePlex
Harry Pierson wrote: The CodePlex team just shipped mailing list support for project discussions. Details are available at http://blogs.msdn.com/codeplex/archive/2008/07/23/codeplex-project-discussions-mailing-lists.aspx. While we've had this mailing list for years, I've spoken to the CodePlex team and it should be possible to make the switch over to the CodePlex infrastructure. However, I wouldn't want to make a change like that without getting some feedback from the community at large. If you've got a strong opinion about CodePlex mailing lists one way or another, please let me know. Is there any *advantage* to switching? This list works fine and is linked to from many places. I'd be -1 on a switch just for the sake of it Michael Foord Harry Pierson Senior Program Mangager, IronPython Visual Studio Managed Languages email : [EMAIL PROTECTED] office : 425/705-6045 mobile : 425/761-0293 weblog : http://devhawk.net Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. - Howard Aiken ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://.theotherdelia.co.uk/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Switching Mailing List to CodePlex
I believe the advantage would be the discussions would be accessible from the web site as well as the mailing list. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, July 24, 2008 1:25 AM To: Discussion of IronPython Subject: [IronPython] Switching Mailing List to CodePlex Harry Pierson wrote: The CodePlex team just shipped mailing list support for project discussions. Details are available at http://blogs.msdn.com/codeplex/archive/2008/07/23/codeplex-project-discussions-mailing-lists.aspx. While we've had this mailing list for years, I've spoken to the CodePlex team and it should be possible to make the switch over to the CodePlex infrastructure. However, I wouldn't want to make a change like that without getting some feedback from the community at large. If you've got a strong opinion about CodePlex mailing lists one way or another, please let me know. Is there any *advantage* to switching? This list works fine and is linked to from many places. I'd be -1 on a switch just for the sake of it Michael Foord Harry Pierson Senior Program Mangager, IronPython Visual Studio Managed Languages email : [EMAIL PROTECTED] office : 425/705-6045 mobile : 425/761-0293 weblog : http://devhawk.net Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. - Howard Aiken ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://.theotherdelia.co.uk/ ___ 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
Re: [IronPython] CLS compilation
I understand multi-year undertakings. I was involved in one, myself, if you recall. J From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Thursday, July 24, 2008 7:40 AM To: Discussion of IronPython Subject: Re: [IronPython] CLS compilation The assumption of static typing is baked pretty heavily into the existing CLR metadata APIs. Consider this runtime scenario; an application has a reference to an object o. It calls o.GetType() to get its type, then uses reflection to get a MethodInfo for the method foo. What does this MethodInfo mean if the foo method on the Python type is changed? Or removed from the type entirely? Or overridden for just this one particular instance of the type? And this is just one example of the semantic gap between static and dynamic types; it's easy to think of others -- like the fact that the line between properties and methods is often blurred in dynamic languages. So it probably doesn't make sense to just say fix the CLR, no matter how pithy it sounds :). And such a project is likely to be a multiyear undertaking anyway, which doesn't help anyone who's got scenarios today that they need to see addressed. That's why we want to understand what those scenarios are; to make sure that we can provide some kind of solution -- whether that's through changes to IronPython or some sample code or even simple guidance. Bottom line: keep those use cases coming! On Thu, Jul 24, 2008 at 12:45 AM, Keith J. Farmer [EMAIL PROTECTED] wrote: As for the rest.. fix the CLR! ;) I would *presume* that changes in certain APIs as well as the runtime would be necessary to truly make .NET dynamic-language-friendly. There's only so far you can go, after all, without it. I'll also respond privately with other stuff. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, July 23, 2008 11:06 PM To: Discussion of IronPython Subject: [IronPython] CLS compilation I am changing the subject to better reflect the discussion. I have posted a blog at http://blogs.msdn.com/shrib/archive/2008/07/24/cls-compilation-of-ironpy thon.aspx discussing some issues I see. Keith, as far as exposing IronPython types as System.Type, its not just a question of inheriting from System.Type. If we did just that, the resulting Type would not be usable from important APIs like Activator.CreateInstance, from IL instructions like newobj, etc. because the CLR has special knowledge about the System.Type object it creates from metadata. Also, LINQ to SQL does look like an interesting scenario. I mention this at the end of the blog. However, the reason to collect real use cases is to know exactly what features are needed. Supporting the full range of CLS features may not be necessary. Knowing how folks are wanting to use the feature can guide the design of the feature in the future. For example LINQ to SQL only needs CustomAttributes on types but not on methods AFAIK. This may could make a significant difference as support CustomAttributes on method is much more complicated. So do send in other use cases you have run into... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, July 23, 2008 7:41 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython Post 2.0 Roadmap The only problem w/ the existing Type and MemberInfo classes is that they all require inheritance demands to inherit from them. That prevents us from subclassing them in anything core because it won't work in Silverlight or other partial trust scenarios. But it is something we've been working w/ the CLR team on getting fixed so we'll be able to take that approach in the future - there's other areas where it'd be useful as well. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Keith J. Farmer Sent: Wednesday, July 23, 2008 7:30 PM To: Discussion of IronPython; Discussion of IronPython Subject: Re: [IronPython] IronPython Post 2.0 Roadmap I can answer both in one: To be able to use IronPython to create data classes, marked up with attributes, to be consumed by APIs probably written in something other than IronPython. That's it.. quite simple. Example of such an API: LINQ to SQL. Or LINQ to whatever, since outside of of Objects and XML, things pretty much end up with mapping metadata and attributes are one of the first places to look for that. And so, in light of the DLR effort, and the general push to make the static languages be able to work well with the dynamics, I think it's only right that the DLR languages be able to expose their dynamic types in such as way as to be transparent to the static languages. That's why I pointed out that Type is an abstract class and the MemberInfo subclasses themselves appear to be subclassable. It really appears that the API is there, waiting to be implemented. Otherwise, really, the dynamic languages are completely
Re: [IronPython] CLS compilation
On Thu, Jul 24, 2008 at 9:07 AM, Keith J. Farmer [EMAIL PROTECTED] wrote: I understand multi-year undertakings. I was involved in one, myself, if you recall. J No, I didn't -- but I do now :). -- Curt Hagenlocher [EMAIL PROTECTED] ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] CLS compilation
As for fix the CLR being pithy: If the intention was that Type never be subclassed by 3rd parties, then Type should never have been made abstract. At most, it should have been sealed, and any polymorphic behavior handled internally using any of the reasonable techniques for doing so. That *not* being the case, newobj should *not* be making such assumptions on Type. So, in this sense, the combination of (CLR + ReflectionAPI) can be said to be broken: the one side implies untrue things about the other. So one or the other needs to give in order to bring Order back (as it were - I've spent way too much time in Northwind the past couple years). My preference would be a change, possibly breaking, to the way the CLR deals with the Type class. Of course, I may be wrong and it may not be breaking, but it may instead just mean the type returned is a snapshot of the type as it exists in the DLR at that time. You would need, obviously, to make the info classes behave like weak references, and include API to detect whether the reference is still valid. You could add other API to say whether it's dynamic at all. There might be a different path involving parallel classes and no CLR changes, but there would still be breaking changes, and it's a worse solution overall, I think. But, in the end, I imagine we'll hear something by PDC about the level of interop they're planning for DLR/CLR languages. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Curt Hagenlocher Sent: Thursday, July 24, 2008 7:40 AM To: Discussion of IronPython Subject: Re: [IronPython] CLS compilation The assumption of static typing is baked pretty heavily into the existing CLR metadata APIs. Consider this runtime scenario; an application has a reference to an object o. It calls o.GetType() to get its type, then uses reflection to get a MethodInfo for the method foo. What does this MethodInfo mean if the foo method on the Python type is changed? Or removed from the type entirely? Or overridden for just this one particular instance of the type? And this is just one example of the semantic gap between static and dynamic types; it's easy to think of others -- like the fact that the line between properties and methods is often blurred in dynamic languages. So it probably doesn't make sense to just say fix the CLR, no matter how pithy it sounds :). And such a project is likely to be a multiyear undertaking anyway, which doesn't help anyone who's got scenarios today that they need to see addressed. That's why we want to understand what those scenarios are; to make sure that we can provide some kind of solution -- whether that's through changes to IronPython or some sample code or even simple guidance. Bottom line: keep those use cases coming! On Thu, Jul 24, 2008 at 12:45 AM, Keith J. Farmer [EMAIL PROTECTED] wrote: As for the rest.. fix the CLR! ;) I would *presume* that changes in certain APIs as well as the runtime would be necessary to truly make .NET dynamic-language-friendly. There's only so far you can go, after all, without it. I'll also respond privately with other stuff. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shri Borde Sent: Wednesday, July 23, 2008 11:06 PM To: Discussion of IronPython Subject: [IronPython] CLS compilation I am changing the subject to better reflect the discussion. I have posted a blog at http://blogs.msdn.com/shrib/archive/2008/07/24/cls-compilation-of-ironpy thon.aspx discussing some issues I see. Keith, as far as exposing IronPython types as System.Type, its not just a question of inheriting from System.Type. If we did just that, the resulting Type would not be usable from important APIs like Activator.CreateInstance, from IL instructions like newobj, etc. because the CLR has special knowledge about the System.Type object it creates from metadata. Also, LINQ to SQL does look like an interesting scenario. I mention this at the end of the blog. However, the reason to collect real use cases is to know exactly what features are needed. Supporting the full range of CLS features may not be necessary. Knowing how folks are wanting to use the feature can guide the design of the feature in the future. For example LINQ to SQL only needs CustomAttributes on types but not on methods AFAIK. This may could make a significant difference as support CustomAttributes on method is much more complicated. So do send in other use cases you have run into... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dino Viehland Sent: Wednesday, July 23, 2008 7:41 PM To: Discussion of IronPython Subject: Re: [IronPython] IronPython Post 2.0 Roadmap The only problem w/ the existing Type and MemberInfo classes is that they all require inheritance demands to inherit from them. That prevents us from subclassing them in anything core because it won't work in Silverlight or other partial trust scenarios. But it is something
Re: [IronPython] Switching Mailing List to CodePlex
Dino Viehland wrote: I believe the advantage would be the discussions would be accessible from the web site as well as the mailing list. The current list is already available for reading on the web via the current list archive and for reading / posting from google groups. Those archives, and links to those archives, would rot if the list was moved... Michael -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Foord Sent: Thursday, July 24, 2008 1:25 AM To: Discussion of IronPython Subject: [IronPython] Switching Mailing List to CodePlex Harry Pierson wrote: The CodePlex team just shipped mailing list support for project discussions. Details are available at http://blogs.msdn.com/codeplex/archive/2008/07/23/codeplex-project-discussions-mailing-lists.aspx. While we've had this mailing list for years, I've spoken to the CodePlex team and it should be possible to make the switch over to the CodePlex infrastructure. However, I wouldn't want to make a change like that without getting some feedback from the community at large. If you've got a strong opinion about CodePlex mailing lists one way or another, please let me know. Is there any *advantage* to switching? This list works fine and is linked to from many places. I'd be -1 on a switch just for the sake of it Michael Foord Harry Pierson Senior Program Mangager, IronPython Visual Studio Managed Languages email : [EMAIL PROTECTED] office : 425/705-6045 mobile : 425/761-0293 weblog : http://devhawk.net Don't worry about people stealing your ideas. If your ideas are any good, you'll have to ram them down people's throats. - Howard Aiken ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://.theotherdelia.co.uk/ ___ 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 -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/ http://www.trypython.org/ http://www.ironpython.info/ http://www.resolverhacks.net/ http://www.theotherdelia.co.uk/ ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Switching Mailing List to CodePlex
Dino Viehland wrote: I believe the advantage would be the discussions would be accessible from the web site as well as the mailing list. I really don't mean to be elitist but recent experience on another mail list that added a Web interface (not on Codeplex) was that it drastically reduced the signal to noise ratio. -- Regards, Graham Bloice ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Switching Mailing List to CodePlex
If you've got a strong opinion about CodePlex mailing lists one way or another, please let me know. I am okay with it provided that all previous links to Mailman archive transparently redirects, forever, to the correct place. Otherwise I am strongly against. (I probably made hundreds of links to the archive of this mailing list, and it's only me.) -- Seo Sanghyeon ___ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
Re: [IronPython] Switching Mailing List to CodePlex
Good point Seo, thanks for pointing that out. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sanghyeon Seo Sent: Thursday, July 24, 2008 4:55 PM To: Discussion of IronPython Subject: Re: [IronPython] Switching Mailing List to CodePlex If you've got a strong opinion about CodePlex mailing lists one way or another, please let me know. I am okay with it provided that all previous links to Mailman archive transparently redirects, forever, to the correct place. Otherwise I am strongly against. (I probably made hundreds of links to the archive of this mailing list, and it's only me.) -- Seo Sanghyeon ___ 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
