Hacker News Reader

Comment by globular-toast | Hacker News Reader

Yeah. Pretty horrible design flaw. Being able to add parameters in a backwards compatible way is essential for software development. I guess the only way to do it is via passing an object, which is like passing keyword parameters in other languages.

View on HN

I don't understand this argument. Let's say you remove a typed param and replace it with a new one of the same type, how will your typed language protect you then? Is that a case that should be handled in a backwards compatible way? Changing a function signature is a breaking change. In some cases like function arity or different types your compiler could catch it and throw errors (and break your program, hence breaking change).

A better language might have a special syntax or specific types for mapping functions but that's not the argument you were making.

If you remove a typed param and replace it with a new one of the same type, typing will indeed not save you. But there should be other checks to warn you:

- Version should be bumped - Dependencies should be informed via the changelog - Existing tests of dependencies should fail

> Changing a function signature is a breaking change

Not if your language has default parameters and does not allow callers to pass "extra" parameters. Then you can easily add a new parameter with a default value and older callers will work as expected.

I forgot to say I meant adding an optional new parameter to a function. Obviously adding a new parameter to a function is a breaking change for any API regardless of language.

Or you end up with java-like names once you forgot the option object. toReabableNumber, toReadableNumberWithBase, toReadableNumberWithBaseAndPrecision, .... or I guess toReabableNumberWithOptions.

uhm java has method overloading..

So does javascript.

I believe that JS doesn't have function overloading. Function overloading, the way I understand it, is the ability to declare multiple functions with the same name but a different signature (different tuple of arguments) and let the runtime/compiler decide upon the implementation used.

JavaScript supports this here is a snippet from out sdk

https://pastebin.com/xCnY8ZzV

That's TypeScript and it works only with type signatures, you still have only one actual implementation.

Isn't that more Objective-C style?

Aaand in objc, it would traditionally be:

  [array mapSelector:@selector(toReadableNumber:withOptions:)
          fromObject:[NSFormattingManager localizedFormattingManager]
       withArguments:@[@{kCFNumberFormattingBaseKey:@(10)}]];

Thank god they invented @-syntax for core type literals.

Reply on news.ycombinator.com