[nem-en] importing extension methods

[Kamil Skalski]

I like the idea of namespace-based loading of extension methods.

About the implementation problems...
Isn't method's declaring GlobalEnv stored somewhere in MethodBuilder?
I thought about just filtering extension method overloads, which comes
from globalEnv, which do not intersect with the current one.
Hm, I guess GlobalEnv are not stored for externally loaded methods, so
maybe the best way would be to implement their creation - it is a nice
feature to have also in context of macros AFAIR.

2006/2/1, Michal Moskal <michal.moskal at gmail.com>:
> Hi,
>
> I started implementation of extension methods. They work for
> non-generic types (this also excludes arrays). They can be saved and
> loaded from assemblies.
>
> What we need now is support for generic types (this shouldn't be
> hard), and a way of enabling only certain extension methods.
>
> People here suggested to make 'using Namespace.Class' enable
> extensions from Namespace.Class. I don't like this idea, because it
> clutters your global namespace with stuff that should be scoped to the
> extended type. That is you don't always want to be able to say
> Split(some_array,1,2) in addition to some_array.Split(1,2).
>
> This is why I think C# used the 'using Namespace' only. This again
> cluters your global namespace with strange stuff, but this time you
> were likely to do it anyway.
>
> The problem is that 'using' has nothing in common with extension
> methods, it just happen to coincide in most cases.
>
> The cleanest solution would be to use 'import Namespace.Class' and
> 'import Namespace.*' but this seems overkill...
>
> So in the end I'm not sure how to resolve this. Waiting for your comments.
>
> --
>    Michal Moskal,
>    http://nemerle.org/~malekith/
>
> _______________________________________________
> https://nemerle.org/mailman/listinfo/devel-en
>


--
Kamil Skalski
http://nazgul.omega.pl