It's always great to see a fellow former c# nut see the light. :)

One tweak to the Ruby example I personally use all the time @Symbol#to_proc@. It's simple coercion just like you'd use in c# for the implicit operator overload during casts.

class Symbol
  def to_proc
    lambda { |x| x.send(self) }
  end
end

The great thing about this is you can use an even shorter notation for @Enumerable#map@. By preceding a method parameter with the & symbol, you're coercing it into a block, so now the @map@ example becomes:

customers.map &:name

It took awhile, but now that's the notation I use regularly for returning a list of single attributes from a list of objects.

If your using .NET 2.0 and your customers are in a generic List you can use the ConvertAll method.

List<customer> customers = ...// get customers List<string> names = customers.ConvertAll(delegate(Customer c) { return c.Name; }));

My syntax might be off a bit since your comment box doesn't appear to have a C# compiler built in :(

I definitely prefer the Ruby syntax but .NET is getting closer by the day. With C# 3.5 the above will be able to become:

var names = customers.Select(c => c.Name);

It's nice to be getting some Ruby'ish like syntax in the .NET world.

Great little example, should help others out there. For the record you can do similiar things in JavaScript if you include the Ruby-inspired prototype library.

The only thing that irks me is when people talk about "seeing the light" in Ruby. Ruby is great, I love it, but I use C# by day, Ruby at night and honestly I spend just as much time pulling my hair out with issues on both sides of the fence, at least for complicated projects. They just have different issues.

Another very small point to quibble over is that using a select THEN a collect iterates twice (granted the second time is much smaller) while the boring, loop-and-compare method only loops a single time. Usually this doesn't matter in the least but I have seen a few Rails sites where they had to go back through and rework the way they stacked Enumerable calls over huge collections.

I do agree with Steve, Microsoft is making some huge improvements in .NET to work with dynamic languages. It'll be nice to have my day and night jobs get closer at least in syntax.

Why the extra lines in C# and not in Ruby? To make it look more verbose?

Anyhow, the C# quivalent would be

public IEnumerable<string> GetNames(Customer[] customers) {

foreach(Customer c in customers) yield return c.Name;

}

and to filter:

public IEnumerable<string> GetNames(Customer[] customers) {

foreach(Customer c in customers) 

    if (c.PurchasedQty>1000) yield return c.Name;

}

You are showing a naiive use of arrays as enumerators. This is a practice common in other languages, but in the .NET world you should think IEnumerable before locking yourself into an array or a list. Incidently a list (and other collection types) can easily be constructed from something enumerable, as one of the constructor takes an IEnumerable.

The yield return is actually a quite nice improvement over list monging. Apart from keeping the syntax brief, it also lets you iterate through a collection incrementally producing the elements. Hence, if you "step out" (break the enumeration) the remaining elements will simply not have been generated.

As mentioned by Steve there's also ConvertAll which match the Ruby collect or map more closely in that it takes a "delegate" (closure; proc whatever) to perform the conversion.

Ruby is a more compact language. Some of it is because the language itself is more dense, but a big part of it in your samples is due to the cultures as well. In C# it good style to spell the methods and parameters out using full (non-abbreviated) words. It's also good practice not trying to do too much on one line; not so much b/c the line length but because each line should be simple to understand.

Just because there a fewer and shorter keywords and the variable names are kept shorter does not mean it's smart to cram everything in one line.

I use a slight variation of this:

customers.map {|cust| cust.purchased_qty > 1000 ? cust.name : nil}.compact

Hi!

If you're under Rails, you can use the following shortcut notation:

customers.select { |cust| cust.purchased_qty > 1000 }.map { |cust| cust.name }

becomes

customers.select { |cust| cust.purchased_qty > 1000 }.map(&:name)

(This situation is very common - hence the shortcut)

regards, and keep on posting! Your blog is especially great for all C# programmers.

"Another very small point to quibble over is that using a select THEN a collect iterates twice (granted the second time is much smaller) while the boring, loop-and-compare method only loops a single time. Usually this doesn't matter in the least but I have seen a few Rails sites where they had to go back through and rework the way they stacked Enumerable calls over huge collections."

You can eliminate the need to loop twice with something like:

customers.inject([]) { |m,cust| m << cust.name if cust.purchased_qty > 1000; m }

It's not nearly as pretty, but I'd probably go with something like this for a large result set. It's also about the same length as the original.

public IEnumerable<string> GetImportantNames(List<customer> customers) { return from c in customers where c.PurchasedQty > 1000 select c.Name; }

I would have to admit I am one of those 95% that never realized that "yield" even existed in C#. Believe me, I have read tons of documentation and use .NET Reflector religiously. With that said, thanks to Jeff for the article and to Zaphop for his comments.

here2367@softiesonrails.com

Multiplicities of an object, consequently, exist for us thanks to experiences.

Our a priori knowledge excludes the possibility of natural causes.

Thanks I was trying to figure this out today!!