3 ms·

Is there any reason why something shouldn't be abstracted? At least in a functional or procedural realm, I don't think that this would be a detriment.

ximeng 10y ago
You can design wide or deep with abstraction. Repeat similar code or abstract it out and branch down. Both introduce complexity. Possible to have too many abstraction layers. https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc Convenient proxy factory bean superclass for proxy factory beans that create only singletons.
slavik81 10y ago
If two things just happen to be similar, you go through a whole lot of work to make them share code, then you go through a whole lot of work to separate them again when one changes.
Ace17 10y ago
Structural equivalence doesn't necessarily means there's some missed abstraction: struct Point { int x, y; } struct Fraction { int num, denom; } Would it be desirable to replace both above definitions by the following "abstraction"? struct StructWithTwoIntegers { int first, second; }
- gravypod 10y ago
  I'd just call it a union. Since it's a union of two integers. Than name of the variables should tell you about what the data means. The data structure should tell you how it's organized in memory. Edit: You can also abstract the data type from the union. You can have unions of other types as well so why have 30+ union types. You can also have unions of more then a single pair. Also I feel that rather then having the data structure represent the meaning, variable-based meaning is the best way to go as it will lead to clearer names. union_t<int> location_coordinate = { x = 0; y = 0; }; This would be accessed by: location_coordinate.x; // == x location_coordinate.y; // == y Rather then location_t position = ...; I personally like longer variable names as it makes it explicitly easy to see exactly how it's expected to behave.
  - Ace17 10y ago
    You just moved the problem. Suppose you have two "add" functions: one for fractions, one for points: Fraction add(Fraction a, Fraction b) { Fraction result; result.num = a.num * b.denom + b.num * a.denom; result.denom = a.denom * b.denom; return result; } Point add(Point a, Point b) { Point result; result.x = a.x + b.x; result.y = a.y + b.y; return result; } How would you write this in C++? Obviously the code below won't do: union_t<int> add_fractions(union_t<int> a, union_t<int> b); union_t<int> add_points(union_t<int> a, union_t<int> b); Because you now just lost type safety (i.e you can add fractions with points). To get back strong type safety, you could write: struct Fraction : public union_t<int> {}; struct Point : public union_t<int> {}; At this point, you're mostly back to square one, except that Fraction users must use members named "x" and "y" ... (and I'm not even talking about operator overloading) (By the way, "union" is an unfortunate choice of words, as the language already defines it to mean something completetly different. Maybe "pair" is more appropriate?).
elcapitan 10y ago
If you analyze the binary, wouldn't you most likely find lots of inlined code anyway? Code that is neatly abstracted already, but which the compiler then optimizes to avoid too many function calls.

ximeng 10y ago

You can design wide or deep with abstraction. Repeat similar code or abstract it out and branch down. Both introduce complexity. Possible to have too many abstraction layers. https://plus.google.com/+aerotwist/posts/1QhcnQizuPc https://plus.google.com/+aerotwist/posts/1QhcnQizuPc Convenient proxy factory bean superclass for proxy factory beans that create only singletons.

slavik81 10y ago

If two things just happen to be similar, you go through a whole lot of work to make them share code, then you go through a whole lot of work to separate them again when one changes.

Ace17 10y ago

Structural equivalence doesn't necessarily means there's some missed abstraction: struct Point { int x, y; } struct Fraction { int num, denom; } Would it be desirable to replace both above definitions by the following "abstraction"? struct StructWithTwoIntegers { int first, second; }

gravypod 10y ago
I'd just call it a union. Since it's a union of two integers. Than name of the variables should tell you about what the data means. The data structure should tell you how it's organized in memory. Edit: You can also abstract the data type from the union. You can have unions of other types as well so why have 30+ union types. You can also have unions of more then a single pair. Also I feel that rather then having the data structure represent the meaning, variable-based meaning is the best way to go as it will lead to clearer names. union_t<int> location_coordinate = { x = 0; y = 0; }; This would be accessed by: location_coordinate.x; // == x location_coordinate.y; // == y Rather then location_t position = ...; I personally like longer variable names as it makes it explicitly easy to see exactly how it's expected to behave.
- Ace17 10y ago
  You just moved the problem. Suppose you have two "add" functions: one for fractions, one for points: Fraction add(Fraction a, Fraction b) { Fraction result; result.num = a.num * b.denom + b.num * a.denom; result.denom = a.denom * b.denom; return result; } Point add(Point a, Point b) { Point result; result.x = a.x + b.x; result.y = a.y + b.y; return result; } How would you write this in C++? Obviously the code below won't do: union_t<int> add_fractions(union_t<int> a, union_t<int> b); union_t<int> add_points(union_t<int> a, union_t<int> b); Because you now just lost type safety (i.e you can add fractions with points). To get back strong type safety, you could write: struct Fraction : public union_t<int> {}; struct Point : public union_t<int> {}; At this point, you're mostly back to square one, except that Fraction users must use members named "x" and "y" ... (and I'm not even talking about operator overloading) (By the way, "union" is an unfortunate choice of words, as the language already defines it to mean something completetly different. Maybe "pair" is more appropriate?).

elcapitan 10y ago

If you analyze the binary, wouldn't you most likely find lots of inlined code anyway? Code that is neatly abstracted already, but which the compiler then optimizes to avoid too many function calls.