Re: Keyword Arguments

On 2012-06-14 Thu, at 05:58 AM, Friedrich Dominicus wrote:
> Steve Dekorte <[email protected]> writes:
>> As objects are about coupling data and logic, if you're passing a lot of
>> arguments(data) around
>> to methods (logic), then it looks suspiciously like you've failed to couple
>> your data and logic.
> 
> I agree with you but there is one area which I will call functional
> abstraction. You can see often that there are quite some long methods
> which are called e.g as constructors.

It seems to me that constructors are the canonical example of how 
multiple args encourage bad design.

They fail to separate the assignments and this leads to repetitive code
for validating the state in the receiver and a combinatorial explosion 
of constructors as the argument count rises. Examples of this problem 
can be found in many (if not most) Java and C++ frameworks. 

I've seen cases were they tried to "solve" the problem by creating special 
classes that held dictionaries for the constructor arguments so the
ability to do an invalid set on an object (which would raise an exception)
was replaced by the ability to do an invalid set on the constructor 
dictionary - progress?

>  I think templates for functions
> are a kind of "counter" example. Well yes if it's get too much you may
> recconsider using classes as Commands but still there are examples where
> at least 2 arguments are "needed" sorting blocks

This is an interesting example because the 2 arguments aren't needed at all
but traditional languages make it easier to implement that way.

In any of these cases, the arguments could be instance variables (what 
are stack frames but objects with one method?) but most languages make it
harder to express that way.

> eg. And if you look
> over to the Common Lispers I  think there multiple dispatch stuff is an
> argument for functions with some more parameters.

I also see multiple dispatch and anti-pattern but that's another discussion.

> But I agree too many parameters suggest that some abstraction might have
> been overseen.

That leaves us with the question: Should we be making it easier to implement 
bad designs than good ones?

Steve