|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |