3 ms·

It's generic, not in the Java-generics sense of the work, but in the sense that x and y are generic names - they don't tell you what x and y are. Yes, they are

It's generic, not in the Java-generics sense of the work, but in the sense that x and y are generic names - they don't tell you what x and y are. Yes, they are of type int, but are they apples or oranges? In the example, they are indeed just two numbers that we chose to keep together, although the name and field names suggest that the author has a point in mind. rationals.Pair is still a poor name, it's a pair of what and for what purpose? Assuming you're referring to rational numbers, ratio struct {p, q int} is better.

dllthomas 13y ago
In my C code I've been moving away from distinguishing primitive types by name alone, preferring to wrap them in single-element structs to get some type safety: do_things_with_fruits(apple_count_t apples, orange_count_t oranges); instead of do_things_with_fruits(int apples, int oranges); Which saves my ass when I wind up writing do_things_with_fruit(basket.oranges, basket.apples); Note that at that point, I would say a generic pair type (not allowed in C but borrowing C++ syntax) pair<apple_count_t, orange_count_t> is really no less informative than something like fruit_basket_t and if it's easily defined (tuples + inference?) I see no reason to avoid it.
- mseebach 13y ago
  Yes, it's less informative, because you're missing the context of why the apples and oranges are lumped together in the pair. FWIW fruit_basket_t is poorly named too, since fruit baskets not things that can count apples and oranges (and nothing else), they are generic containers capable of holding all kinds of fruit. I like the single-element structs. I've been finding myself doing that more and more in Java and I quite enjoy it. First epiphany was replacing bool with enums.
  - dllthomas 13y ago
    I don't think "fruit_basket" (or "fruit_counts", say, addressing your later point) really gives much more clue as to why you're grouping these things than does the templated pair. When there is an informative name, use it, to be sure. Occasionally there's not much more reason than "I am using both of these elsewhere. This is much more the case when things are used locally than when they are exposed in interfaces, to be sure.

dllthomas 13y ago

In my C code I've been moving away from distinguishing primitive types by name alone, preferring to wrap them in single-element structs to get some type safety: do_things_with_fruits(apple_count_t apples, orange_count_t oranges); instead of do_things_with_fruits(int apples, int oranges); Which saves my ass when I wind up writing do_things_with_fruit(basket.oranges, basket.apples); Note that at that point, I would say a generic pair type (not allowed in C but borrowing C++ syntax) pair<apple_count_t, orange_count_t> is really no less informative than something like fruit_basket_t and if it's easily defined (tuples + inference?) I see no reason to avoid it.

mseebach 13y ago
Yes, it's less informative, because you're missing the context of why the apples and oranges are lumped together in the pair. FWIW fruit_basket_t is poorly named too, since fruit baskets not things that can count apples and oranges (and nothing else), they are generic containers capable of holding all kinds of fruit. I like the single-element structs. I've been finding myself doing that more and more in Java and I quite enjoy it. First epiphany was replacing bool with enums.
- dllthomas 13y ago
  I don't think "fruit_basket" (or "fruit_counts", say, addressing your later point) really gives much more clue as to why you're grouping these things than does the templated pair. When there is an informative name, use it, to be sure. Occasionally there's not much more reason than "I am using both of these elsewhere. This is much more the case when things are used locally than when they are exposed in interfaces, to be sure.