Timeline for Is it inadvisable to make a function that essentially renames a built-in function?
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 23, 2017 at 12:40 | history | edited | CommunityBot |
replaced http://stackoverflow.com/ with https://stackoverflow.com/
|
|
| Jun 10, 2016 at 1:24 | comment | added | Tim Grant | OK, I edited the answer to use "apply_upper_bound" which both fits the OP's reasoning and avoids overloading terminology. Verbosity is not a problem. I'm not setting out to write the perfect method name here, just set some ground rules for naming aliases. The OP can edit it to whatever he finds most clear and concise. | |
| Jun 10, 2016 at 1:17 | history | edited | Tim Grant | CC BY-SA 3.0 |
Incorporated function name from comment
|
| Jun 9, 2016 at 17:44 | comment | added | Fattie | This policy "Aliasing a function is fine, but don't try to change the meaning of existing terms" is perfect and beautifully expressed. Secondly, the idea that you should not rename in a way which is confusing in relation to built-in functions (and: even if the built in functions are poorly named / stupid / confusing) is a perfect idea. Re the max/min example which came up on this page, it's total confusion heh. | |
| Jun 9, 2016 at 12:18 | comment | added | Caridorc |
In functional languages (even Python) you may write get_lower_value = min to simplify.
|
|
| Jun 9, 2016 at 9:11 | comment | added | Steve Jessop | I think you're essentially relying on the reader not to be too familiar with the word supremum, so that they take your meaning rather than the English meaning. It's fine to define jargon local to your code, but kind of the point of the question is what do do when the jargon you want directly contradicts an already-familiar meaning, and I'm afraid I think you're still doing that (for some version of "English" relevant only to those who've studied STEM subjects) | |
| Jun 9, 2016 at 8:51 | comment | added | leftaroundabout |
One good way to avoid the ambiguity of supremum would also be to curry it, so supremum(s) is a “capping operator”. I really don't think anybody would read (supremum(4)) (5) as sup {4,5}.
|
|
| Jun 9, 2016 at 8:44 | comment | added | leftaroundabout |
@SteveJessop: indeed, it's a bit the same problem as with max. The reason I still think supremum is better is that the term is usually only applied to infinite sets, where often the supremum is not in the set itself, so it should be pretty clear that supremum (s, x) doesn't refer to sup({s, x}) but to s = sup({f x : x ∈ ℝ}). Now, apply_upper_bound would of course be completely unambiguous, but it's rather too verbose for my taste. I suppose 5gon12eder's suggestion cap is not too bad.
|
|
| Jun 9, 2016 at 8:19 | comment | added | Steve Jessop |
@leftaroundabout: the supremum of the set {1, 2} is 2, so do not use the name supremum for the function get_lower_value that's defined above to just call min. It causes the next programmer exactly the same problem as calling it maximise. I'd suggest calling it apply_upper_bound, but I'm not sure that's perfect. It's still odd because it works the same whichever way around you put the parameters, but the name implies that one of the parameters is "the value" and the other is "the bound", and that they're somehow different.
|
|
| Jun 8, 2016 at 23:39 | comment | added | leftaroundabout |
I think you've misunderstood the application of min and max which confuses the OP. It's when min is used to set a fixed upper boundary on some value. get_lower_value would be just as counterintuitive in this application. If I were to choose an alternative name for this operation, I'd call it supremum, though I'm not sure how many programmers would immediately understand that.
|
|
| Jun 8, 2016 at 19:52 | review | First posts | |||
| Jul 8, 2016 at 19:48 | |||||
| Jun 8, 2016 at 19:46 | history | answered | Tim Grant | CC BY-SA 3.0 |