On 17.09.2015 23:56, Ryan Gonzalez wrote:

Embedding type names in arguments and method names.

On Thu, Sep 17, 2015 at 4:45 PM, Sven R. Kunze <srkunze@mail.de> wrote:

On 17.09.2015 23:19, Ryan Gonzalez wrote:

def process_integer_coordinate_tuples(integer_tuple_1, integer_tuple_2, is_fast): ...

vs

def process_coords(t1: Tuple[int, int], t2: Tuple[int, int], fast: bool): ...

Java's fatal mistake.

Care to elaborate?

I was actually confused by 'Java' in your reply.

You said:

> Even good variable names can leave the type ambiguous.

These are names that don't leave anything ambiguous! :D

They just do. Because they don't tell me why I would want to call that function and with what.

If any of these versions is supposed to represent good style, you still need to learn a lot.

Really, though: relying on naming to make types explicit fails badly whenever you start refactoring and makes hell for the users of the API you made.

Professional refactoring would not change venerable APIs. It would provide another version of it and slowly deprecate the old one.

Not sure where you heading here but do you say t1 and t2 are good names? Not sure how big the applications you work with are but those I know of are very large. So, I am glad when 2000 lines and 10 files later a variable somehow tells me something about it. And no "Tuple[int, int]" doesn't tell me anything (even when an IDE could tell that).

Most of the time when discussing typecheckers and so forth, I get the feeling people think most applications are using data structures like tuples of tuples of tuples of ints. That is definitely not the case (anymore). Most of the time the data types are instances, list of instances and dicts of instances.

That's one reason I somehow like Jukka's structural proposal because I actually can see some real-world benefit which goes beyond the tuples of tuples and that is: inferring proper names.

Best,
Sven