4 ms·
A lot of the time that type names end up in method parameters, it's due to a lack of support of overloading in the language. In particular, isn't Dart (the lan
by yoklov 10y ago
A lot of the time that type names end up in method parameters, it's due to a lack of support of overloading in the language.
In particular, isn't Dart (the language described here) one such language? It's been a while since I used it, and I never wrote much, but I at least thought that was the case.
- _1 10y agoYou are correct. The feature request for adding type-based overloaded function was denied: https://github.com/dart-lang/sdk/issues/49#issuecomment-108301493 https://github.com/dart-lang/sdk/issues/49#issuecomment-1083... > If you need a different variant of a method, create a method with a different name. ... type-based overloading is a bad idea, creating brittleness and ambiguity.
- afsina 10y agoHow about this? They might have changed their minds.. https://github.com/dart-lang/sdk/issues/26488 https://github.com/dart-lang/sdk/issues/26488
- munificent 10y agoYes, overloading is back on the table. All of the cons with it are still there—it really is a hairy feature—but the pros are real too and might be worth doing. We still haven't figured out whether or not we will and, if so, what the exact semantics will be.
- _yosefk 10y agoI used to like how overloading lets you call it sort instead of sortRectsByArea but over the years came to the opposite conclusion. Very short and generic names are great for locals or for truly generic functions but generally a function name shouldn't be too generic IMO, both because grep has its uses regardless of IDE support and because it makes it less necessary to look up definitions. mergeTableCells is better than merge even if you know it's passed a list<TableCell> because merge could be merging the cells or the cell contents or who knows what else, and because looking up the type of the argument costs in itself (as it's not always a local declared right near the call and even if it is, the type might not be spelled out in the declaration.) Also, reusing names through overloading without providing actual polymorphism, either run time or compile time, is IMO bad, as in I don't get what's there to like. If one open function gets a file name and another gets a username and a password, what's so great in that they have the same name?
- xapata 10y agoRather than ``sortRectsByArea`` I'd rather have a generic ``sort`` that supports a Schwartzian transform, like Python's ``sorted(stuff, key=transform)``. Function or method names that postfix the mode onto the verb, like "parse_from_file", are usually an indication that the design could be improved by creating a consistent interface for the various modes. Sometimes it's better to provide a handful of modes, but I always double-check when I see myself writing names like that. [0] https://en.wikipedia.org/wiki/Schwartzian_transform https://en.wikipedia.org/wiki/Schwartzian_transform [1] https://docs.python.org/3/library/functions.html#sorted https://docs.python.org/3/library/functions.html#sorted
- marcosdumay 10y agoThat depends a lot on your actual architecture and domain. Some times, you need parse_from_file, and nothing else. Other times it's worth parametrizing everything and just assembly generic code at the top level.
- kerkeslager 10y ago> A lot of the time that type names end up in method parameters, it's due to a lack of support of overloading in the language. This is true, but that's a code smell if the language supports interfaces (I don't know much about Dart, but it appears that Dart does support interfaces).