[IronPython] Similarity with builtin types

[mlkjih mlkjih]

What about some sort of switcher to enable ironpython specific features?

import allow_builtin_type_extensions

2010/8/9 Dino Viehland <dinov at microsoft.com>

>  Because you can’t do that in CPython.  If we enabled that we’d certainly
> instantly start failing a number of tests and we might subtly break
> compatibility of libraries that might try do assign, catch a
> TypeError/AttributeError, and then do something else (even if that sounds
> like a terrible idea).
>
>
>
> I also think it’s nicer to be explicit here that you’re doing something
> which requires IronPython by forcing the “import clr” so that it’s clearer
> this code won’t work on CPython.
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *mlkjih mlkjih
> *Sent:* Monday, August 09, 2010 10:58 AM
> *To:* Discussion of IronPython
> *Subject:* Re: [IronPython] Similarity with builtin types
>
>
>
> >We won’t ever support Ruby’s mutation of everything under the sun
> including built-in types simply because that’s not something CPython
> supports.
>
> With clr.LoadClrExtensions using C# extension methods we can extend builtin
> types,
> public string DoSomething(this string str) ...
> so why not just allow use ironpython for this?
> String.DoSomething = ...
>
>  2010/8/9 Dino Viehland <dinov at microsoft.com>
>
> As far as extension methods go – and just extension methods – we may at
> some point in time support them.  We won’t ever support Ruby’s mutation of
> everything under the sun including built-in types simply because that’s not
> something CPython supports.
>
>
>
> The tricky part w/ the extension methods is doing it in a way which is
> per-module instead of at a global scope.  In Ruby so much code mutates
> object that it’s not really a big deal to add in some more mutation of types
> across the system.  But w/ Python these sort of changes have always been
> more closely scoped – for example look at from __future__ import … which
> effects only the current module.  Another example is our own “import clr”
> which makes .NET attributes available on the built-in types.
>
>
>
> I suspect what we’ll end up doing is something like:
>
>
>
> clr.LoadClrExtensions(namespace)
>
>
>
> So it’d end up looking like:
>
>
>
> import System
>
> Import clr
>
> clr.AddReference(System.Linq)
>
>
>
>
>
> I do want to do something to continue to push LINQ forward for 2.7 and
> maybe this will be it if I can get it in…  Tomas added the metadata reader
> which we can use to efficiently get the extension methods and I think I
> might have an idea on how to efficiently share the extension methods across
> modules.
>
>
>
> So I guess the question now would be does that look like a reasonable way
> to load extension methods?
>
>
>
>
>
> *From:* users-bounces at lists.ironpython.com [mailto:
> users-bounces at lists.ironpython.com] *On Behalf Of *mlkjih mlkjih
> *Sent:* Monday, August 09, 2010 9:10 AM
> *To:* users at lists.ironpython.com
> *Subject:* [IronPython] Similarity with builtin types
>
>
>
>
> http://ironpython.net/documentation/dotnet/dotnet.html#similarity-with-builtin-types
> What's the point? Is there any plans to support extension methods,
> something like IronRuby's *using_clr_extensions? With immutable types it
> cannot be done, am I right?*
>
>
> _______________________________________________
> 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/20100809/63ca80ec/attachment.html>