Warp wrote:
>   The idea with having objects rather than raw data is that objects can
> be made abstract, ie. have an abstract public interface which hides the
> implementation).

So why is it better to have member functions at all, vs just passing the 
object to a function?  What's the benefit of being able to say
    p = pixels[23].lightened();
vs
    p = lightened(pixels[23]); // Like you would in Java

>   I don't see how "anObject.someFunction()" hides the implementation
> better than "someFunction(anObject)", 

Because it looks like it's part of the class. You don't have to remember 
which members are built in and which ones were added by a library you're using.

For example, there's LINQ (which is sort of 
relational-queries-on-all-data-types), which adds all sorts of query 
semantics to built-in enumerations and such. So you can do something like

  var people = new array[] {
     new Person("Fred", ...),
     new Person("Steve", ...),
       ....
     };
  var query = people.Where(p=>p.Name.startsWith("S"))
                    .Select(p=>p.Name.toUpper());

That gives you back an enumeration over the uppercased names of the people 
in the array whose name starts with "S". The "Where" and "Select" names were 
added by LINQ.

But yeah, it's syntactic sugar. It lets you add methods to classes (and 
their subclasses) that are already in existence without modifying the 
already-compiled classes.  It's syntactic sugar, in the same way that any 
distinguished-caller syntax in a method-oriented OO language is syntactic sugar.

-- 
   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