[IronPython] CLS compilation
Keith J. Farmer
kfarmer at thuban.org
Thu Jul 24 18:07:10 CEST 2008
I understand multi-year undertakings. I was involved in one, myself, if
you recall. J
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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 <kfarmer at thuban.org>
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: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] 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: users-bounces at lists.ironpython.com 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 <kfarmer at thuban.org>
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
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Reflection.ICustomAttributeProvider/GetC
ustomAttributes(Boolean):Object%5b%5d> (bool
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Boolean> inherit);
object
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Object> [] GetCustomAttributes
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Reflection.ICustomAttributeProvider/GetC
ustomAttributes(System.Type,Boolean):Object%5b%5d> (Type
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Type> attributeType, bool
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Boolean> inherit);
bool
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Boolean> IsDefined
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Reflection.ICustomAttributeProvider/IsDe
fined(System.Type,Boolean):Boolean> (Type
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Type> attributeType, bool
<http://www.aisto.com/roeder/dotnet/Default.aspx?Target=code://mscorlib:
2.0.0.0:b77a5c561934e089/System.Boolean> inherit);
}
So I think, actually, that this could be done without changing much if
any external API. They'd probably need to change some of the internals
to return dynamic variants of the info types, but I think that's doable.
________________________________
From: users-bounces at lists.ironpython.com on behalf of Harry Pierson
Sent: Mon 7/21/2008 12:59 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
All of the many overloads of GetCustomAttributes
(http://msdn.microsoft.com/en-us/library/system.attribute.getcustomattri
butes(VS.85).aspx) need some type of static type info (Type, MemberInfo,
ParameterInfo). So supporting custom attributes would require some type
of static class as Michael mentions below.
-----Original Message-----
From: users-bounces at lists.ironpython.com
[mailto:users-bounces at lists.ironpython.com] On Behalf Of Michael Foord
Sent: Monday, July 21, 2008 12:48 PM
To: Discussion of IronPython
Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
Keith J. Farmer wrote:
> Attributes can be applied to more than just types -- members,
> parameters, return values (as I recall), etc.
But those all presuppose a static type - right?
IronPython could generate a static class in the compile phase where .NET
attributes are used. Python decorator syntax could be used - class
decorators are now part of Python 2.6 and no-one would object to you
sneaking them into Python 2.5...
Parameter and return type attributes could still use a method decorator
to apply them.
Michael
>
>
------------------------------------------------------------------------
> *From:* users-bounces at lists.ironpython.com on behalf of Curt
Hagenlocher
> *Sent:* Mon 7/21/2008 9:51 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] IronPython Post 2.0 Roadmap
>
> "Availability of a static type" not because IronPython would need to
> access one but because it would need to expose one.
>
>
> On Mon, Jul 21, 2008 at 9:44 AM, Keith J. Farmer <kfarmer at thuban.org
> <mailto:kfarmer at thuban.org>> wrote:
>
> You can create your own attribute classes, for whatever markup.
> Particularly since LINQ-to-*, where they often are used to
> annotate data classes with strings, etc (not references to types).
>
> In any event, why does "availability of a static type" enter into
> this? IP can access static types just as well as any other .NET
> language (System.Math comes to mind). The motivation in general
> is to make IP a better producer for CLR types, rather than just a
> consumer, and attributes are an increasingly important thing to
> support.
>
> As for expression trees and extension methods, those are to make
> IP a better consumer of a very important API (LINQ and the
> IQueryable stack from .NET 3.5).
>
> To be honest, once those 3 features are available in IP, I think
> it would be on par with the mainstream languages in being very
> usable in an exclusive sense.
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>
> [mailto:users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>] On Behalf Of Harry
> Pierson
> Sent: Sunday, July 20, 2008 11:14 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
>
> Can you give me some examples where you would use these? The
> problem I see is that many scenarios (WCF contracts, XML
> serialization just to name two) where people want to use a custom
> attribute depends on the availability of a static type.
>
> Harry
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>
> [mailto:users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>] On Behalf Of Keith J.
> Farmer
> Sent: Saturday, July 19, 2008 8:13 PM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
>
> votes++
>
> -----Original Message-----
> From: users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>
> [mailto:users-bounces at lists.ironpython.com
> <mailto:users-bounces at lists.ironpython.com>] On Behalf Of Michael
> Foord
> Sent: Saturday, July 19, 2008 10:38 AM
> To: Discussion of IronPython
> Subject: Re: [IronPython] IronPython Post 2.0 Roadmap
>
> Sanghyeon Seo wrote:
> > 2008/7/20 Harry Pierson <Harry.Pierson at microsoft.com
> <mailto:Harry.Pierson at microsoft.com>>:
> >
> >> Hosting features are all done via the DLR, so that's a separate
> team. As for
> >> "ability to interact with the rest of the .Net framework", can
> you be more
> >> specific about what you're looking for in that space? What
> *isn't* IPy doing
> >> that you want it to?
> >>
> >
> > .NET attributes?
> >
> >
> +1 :-)
>
> Michael
>
> --
> http://www.ironpythoninaction.com/
> http://www.voidspace.org.uk/
> http://www.trypython.org/
> http://www.ironpython.info/
> http://www.theotherdelia.co.uk/
> http://www.resolverhacks.net/
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
> _______________________________________________
> Users mailing list
> Users at lists.ironpython.com <mailto:Users at lists.ironpython.com>
> http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
>
>
>
------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at 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.theotherdelia.co.uk/
http://www.resolverhacks.net/
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
_______________________________________________
Users mailing list
Users at lists.ironpython.com
http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/ironpython-users/attachments/20080724/bb284238/attachment.html>
More information about the Ironpython-users
mailing list