Re: Keyword Arguments

On 2012-06-15 Fri, at 02:02 AM, Kevin Edwards wrote:
> As a simple and contrived example, consider a Rectangle object.  Do we package that as 2 Points (x1, y1) and (x2, y2)?  Or as 2 Ranges (x1, x2) and (y1, y2)?  Or flat (x1, x2, y1, y2)?  In OO, if we implement the logic for one format (like intersect, union, expand, contract, etc.), then we either have to convert to/from the other formats (more data moves), or we'll have to (manually) duplicate the core logic for each format we use (which can impact development time and locality due to size).

Exactly, we can ask the other object to describe itself in a way we understand. While FP would require large switch statements scattered around all the functions of the system to handle every type - all of which would break upon the introduction of a new type.

>>> Every 2+ argument method call can be rewritten as a series of 1 argument method calls which configures the object/frame.  e.g. :
>>> 
>>>   meth(a=1, b=2, c=3)  <->  Meth clone setA(1) setB(2) setC(3) result
>>> 
>>> Both versions can have the same massive, monolithic implementation of logic with just a difference in packaging.
>> 
>> Right, the difference is that the method instance is used once and discarded so the sender has to hold the data that was passed and pass it in again on each call. We are left asking if the data shouldn't belong to the receiver instead of being communicated each time.
> 
> I agree.  So if we provide a simple way to hold the data rather than discarding it, would the difference just be syntactic?

Not AFAICS, The idea is to change the design of the code such that you don't need to keep passing the data.

For example, suppose you had a Person object and every person has a age but for some reason you didn't make the age a slot on Person so every time you called any methods that might possibly need the name you would have to pass it in.

Example:

aPerson setAge(thePersonsAge)
aPerson print
aPerson canRetire

vs.

aPerson print(thePersonsAge)
aPerson canRetire(thePersonsAge)

etc

It's clear that the age is being stored in the wrong place and that passing it in constantly is a bad design choice.
To me this suggests that anything that encourages developers to pass more data also encourages them to make bad design decisions.

> You also mentioned validation elsewhere.  e.g. setA can perform validation.  `a=1` could perform validation, too, couldn't it?  More generally, I like the idea of custom setters and setSlot using the same syntax and control path (the same as any dict for that matter).

Well, you can get this by using ::= to create the slot and then calling the setter method (which is considered good coding practice) instead of using = .
Also, you might look at how self unified assignment with methods. Maybe there is something there.

> i think part of the answer to performance is a more flexible dispatcher which can take the `at` and `put` together, so that an explicit Slot object doesn't actually have to be created if it doesn't already exist.  But this may bear some similarity to multiple dispatch, so I'm interested in learning your thoughts about that anti-pattern. :-)

Multiple dispatch makes the deep assumption that a notion of external type exists. But what notion of type can deal with something like a proxy which is, in effect, all possible types? Or from another angle: any system that depends on a notion of type that is anything more than asking an object what it choses to do at the moment violates encapsulation in ways that have serious consequences for what the system can and can't do.

Steve