nemesis wrote:
> More OO, or more assemblyish?  I mean, you individually feed the stack 
> and then call a function using those arguments already in the stack. ;)

Well, no, it's not a stack, it's an object. And each call can, for example, 
set error codes or throw exceptions or some such. So if there's no 
letter-sized paper loaded, the call to set letter size might throw an 
exception you could handle.

As I said, it has some drawbacks, but some benefits too, primarily in the 
areas of subclassing and reuse. Passing all the arguments you need to 
print() is the procedural way of doing it. Passing an object to print() with 
all the parameters set (and which you can, for example, clone and pass 
around) is the OO way to do it.

You could create the printjob object and initialize it in one library and 
invoke print() in another, which you can't do with the default-args approach.

> Named arguments and the above more OO and barroque way do not.

 From experience, it only seems baroque if you're not used to it. Once you 
realize the benefits, and you find that the benefits outweigh the verbosity, 
it's quite nice.

Kind of like the whole command/query separation.  A bit more verbose, but 
also more clear and maintainable. (Command/query separation is basically 
that only functions that don't return a value are allowed to modify the 
object. Or, in C++ terms, all non-const methods must be void.)

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