[Ironruby-core] Linq etc.

[John Messerly]

Brent Rowland:

> Rather than monkey patching Enumerable--thereby affecting (and
> possibly tromping over) every object of every class that includes
> it--how about extending objects on a case-by-case basis?

Hey, this is Ruby, we like to tromp over everything :)
Keep in mind Enumerable would resolve its method after the class it's included in, so it typically wouldn't hide existing methods.

> I've made good use of patterns like the following:
>
> foobar = foo.map { |f| bar(f) }.extend(Statistics) avg = foobar.avg
> (:bam)
>
> (where Statistics is a mixin module that implements sum, avg, etc,
> which make use of the enumerable methods)
>
> This way any function--including 3rd-party code--that returns an array
> or other enumerable type can be extended on-the-fly and new functions
> can return "pre-enriched" collections when appropriate.
>
> numbers = [5, 10, 8, 3, 6, 12].extend(System::Linq) numbers.where {
> |num| num % 2 == 0 }.order_by { |n| n }.each { |i| write("#{i} ") }

Would you really want to do it on a per-object basis though? That's even more finer grained than the C# model. Certainly gives you more control, but I imagine having to do "extend" everywhere could get tedious.

(what we really need here is the Ruby feature "selector namespaces" ... :) )

Anyway, we could certainly show the names on a per file basis, e.g. "using System::Linq". That might be best.

Of course, there's also the option to ignore this problem entirely, and just support the static call syntax:

X = System::Linq::Enumerable.where(numbers) { |num| num % 2 == 0 }
System::Linq::Enumerable.order_by(x) { |n| n }.each { |i| write("#{i} ") }

That seems pretty bad, however. But maybe it could be hidden behind some SQL-like DSL magic.

- John