4 ms·

A language with keyword arguments helps against this. Crystal has a great compromise IMO where you can call the same arguments positionally and as keywords base

by julik 7y ago

A language with keyword arguments helps against this. Crystal has a great compromise IMO where you can call the same arguments positionally and as keywords based on the argument name.

wildlogic 7y ago
same goes with python - def foo(x=None, y=None): ... foo(x=1, y=2) foo(1, y=2) foo(1, 2)
- DonaldPShimoda 7y ago
  You can also disable positional handling via * to require keywords in function calls, e.g.: def add(*, l, r): return l + r add(l=1, r=2) >>> 3 add(1, r=2) >>> [...] >>> TypeError: add() takes 0 positional arguments but 1 positional argument (and 1 keyword-only argument) were given I believe 3.8 is adding / (I think) to do the same but for positional arguments, i.e., arguments you cannot give by keyword.
- echelon 7y ago
  Just be careful not to use mutable objects as your default args.
  - emptysea 7y ago
    A great reason to add flake8 to your CI edit: forgot that flake8 doesn't check for mutable arguments by default – need to add https://github.com/PyCQA/flake8-bugbear https://github.com/PyCQA/flake8-bugbear
    - j88439h84 7y ago
      Pylint does
XorNot 7y ago
The problem with keywords is the compiler can know nothing of intent with them - consider: CopyFile(from: loaded_file, to: report_file) Now, somewhere else off in the code someone does something like: // loaded_file is now the report - so no worries. loaded_file = report_file And the compiler then happily propagates that. At no time does it throw an error saying something which would be quite informative such as "Cannot assign report_file (type: outputFile) to loaded_file (type: sourceFile). Which is really what we want to have happen because - at the very least it forces the developer to go inspect the usage sites to figure out if what they're doing makes sense.
- EdwardDiego 7y ago
  Languages that prefer immutable variables by default would be a better solution for that than introducing two new types, surely. Reassignment of a variable should be a code smell in nearly all contexts that don't involve a loop.
- theemathas 7y ago
  At least that can be determined to be buggy without checking the documentation of CopyFile
- tom_mellior 7y ago
  > At no time does it throw an error saying something which would be quite informative such as "Cannot assign report_file (type: outputFile) to loaded_file (type: sourceFile). Java has InputStream/OutputStream. C++ has istream/ostream. If you use a statically typed language that doesn't have this distinction, blame that specific language's library design. This is orthogonal to keywords.
  - XorNot 7y ago
    Is it? Until you open the file as a stream, the data to do so is kicking around your code as a string type with compiler checks on usage. You're making my point: a compile time check is much more helpful.
    - 7y ago

by julik 7y ago

A language with keyword arguments helps against this. Crystal has a great compromise IMO where you can call the same arguments positionally and as keywords based on the argument name.

wildlogic 7y ago

same goes with python - def foo(x=None, y=None): ... foo(x=1, y=2) foo(1, y=2) foo(1, 2)

DonaldPShimoda 7y ago
You can also disable positional handling via * to require keywords in function calls, e.g.: def add(*, l, r): return l + r add(l=1, r=2) >>> 3 add(1, r=2) >>> [...] >>> TypeError: add() takes 0 positional arguments but 1 positional argument (and 1 keyword-only argument) were given I believe 3.8 is adding / (I think) to do the same but for positional arguments, i.e., arguments you cannot give by keyword.
echelon 7y ago
Just be careful not to use mutable objects as your default args.
- emptysea 7y ago
  A great reason to add flake8 to your CI edit: forgot that flake8 doesn't check for mutable arguments by default – need to add https://github.com/PyCQA/flake8-bugbear https://github.com/PyCQA/flake8-bugbear
  - j88439h84 7y ago
    Pylint does

XorNot 7y ago

The problem with keywords is the compiler can know nothing of intent with them - consider: CopyFile(from: loaded_file, to: report_file) Now, somewhere else off in the code someone does something like: // loaded_file is now the report - so no worries. loaded_file = report_file And the compiler then happily propagates that. At no time does it throw an error saying something which would be quite informative such as "Cannot assign report_file (type: outputFile) to loaded_file (type: sourceFile). Which is really what we want to have happen because - at the very least it forces the developer to go inspect the usage sites to figure out if what they're doing makes sense.

EdwardDiego 7y ago
Languages that prefer immutable variables by default would be a better solution for that than introducing two new types, surely. Reassignment of a variable should be a code smell in nearly all contexts that don't involve a loop.
theemathas 7y ago
At least that can be determined to be buggy without checking the documentation of CopyFile
tom_mellior 7y ago
> At no time does it throw an error saying something which would be quite informative such as "Cannot assign report_file (type: outputFile) to loaded_file (type: sourceFile). Java has InputStream/OutputStream. C++ has istream/ostream. If you use a statically typed language that doesn't have this distinction, blame that specific language's library design. This is orthogonal to keywords.
- XorNot 7y ago
  Is it? Until you open the file as a stream, the data to do so is kicking around your code as a string type with compiler checks on usage. You're making my point: a compile time check is much more helpful.
  - 7y ago