Warp wrote:
>   So instead of writing a function which takes two objects and returns
> a bool, you write a "member function" which which called with one object,
> takes another as parameter, and returns bool?

Yes.

>   I'm still not seeing the huge difference.

That it's the same syntax regardless of whether it's a member function or a 
function the user added later, which makes it easier for code generators. 
Just like having operator= on classes makes it easier to write templates 
than if you had to know whether to use (i = j) for integers and i.equals(j) 
for complex numbers.

That you don't have to remember which functions were added after the fact 
and which functions were part of the original class.

That you can chain a sequence of calls together that are both members and 
non-members without having to skip back and forth around the line to figure 
out what order they get evaluated in.

Writing
   myCollection.Select(...).Group(...).Transform(...).Sort(...).Output()
is a lot more clear than
   Sort(Group(myCollection.Select(...)).Transform(...)).Output()
just like writing
   a = b + c * d - e
is more clear than
   a = subtract(add(b, multiply(c, d)), e)

It isn't a "huge" difference, any more than operator overloading makes a 
"huge" difference to the language.  But that's why it's there.  If you don't 
see why it's a benefit, you either should just let it go, or read the C# 
spec that relates it to the other features of C#.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message