3 ms·

What advantage would a Point3D class have over, say, a Point3D data-structure here? (ernest question) Is it the interface it provides, the types, the coupling

by sordina 15y ago

What advantage would a Point3D class have over, say, a Point3D data-structure here? (ernest question) Is it the interface it provides, the types, the coupling of methods to data, or something else?

colomon 15y ago
I'd say the advantages are: 1) Naming it vastly clarifies further data structures and interfaces. (This is shared with having a Point3D data-structure, obviously.) 2) Providing functions and operators specific to the type. At it's simplest (and possibly most compelling) it's the difference between needing to say p.x = p0.x + t * (p1.x - p0.x); p.y = p0.y + t * (p1.y - p0.y); p.z = p0.z + t * (p1.z - p0.z); and p = p0 + t * (p1 - p0); The latter is easier to type, easier to understand, and less error prone. It's a huge win, especially in more complicated expressions. Now of course, your language may allow you to define data structure-specific functions and operators. But at that point, what you've got is essentially a class, even if you call it something else. (PS Note that data hiding is completely unimportant here, and inheritance would be nothing but trouble.)
- sixbrx 15y ago
  I think there is no question that being able to define new types is important. I don't, however think it's clear that having to pack operations that operate on the types into the types themselves is a good idea in general. Your example is easily handled with a simple type class in Haskell e.g., and no there's it's not "essentially a class" in the OO sense, as new operations can be freely added without modifying the type itself.
  - colomon 15y ago
    Er, I've never used a OO language that didn't allow you to add new operations freely without modifying a class. Not all of them allow you to add new methods, sure, but new functions and operators are par for the course. And surely you're not arguing the defining feature of a class is that it's closed?
- gruseom 15y ago
  I agree with you that Point3D-type-thingies are a sweet spot, though your operator-overloaded line is not doable in most class-based languages, and indeed is generally controversial in OO, so I don't think it gets to count here. That aside, you're quite right that when one has a common construct that permeates the entire program, one badly wants to give it first-class status in the language. What I've noticed, though, is that these constructs don't tend to get involved in complex object graphs (or if they do, they're leaf nodes). Rather, they tend to be atomic and universal (i.e. interoperable with anything) and simple. So I wonder if what one really wants here is the ability to add new primitives to the language. That's potentially quite different from classical classes. It's more related to the "build up a language that fits the problem, then code the solution in that language" idea.
  - colomon 15y ago
    You might guess from my example how little respect I have for the "don't overload operators" argument. All I can say is, all the OO languages I've spent any time programming do indeed let you do that, and I'm sorry for you if your experience is otherwise. So clearly I agree that adding primitives is an extremely important ability. But it's already nearly if not completely there in all the OO languages I use, using classes. I don't think primitives are enough, though. The interface / implementations of interfaces combination is also essential to my programming. Being able to say "Curve" and have it mean Straight or NURBS curve or Circle or Offset curve or Composite curve or... is another huge simplifying device. In fact, I've just looked at my code, and I have 15 distinct curve types, at least 5 of which I'd have missed if you asked me to list them, despite having written all of them over the years. That is exactly the power of simplifying abstraction. Let me point out that given a sufficiently capable OO language, this doesn't need inheritance to implement. This is just the implementation of a role or interface. But it does need classes.

by sordina 15y ago

What advantage would a Point3D class have over, say, a Point3D data-structure here? (ernest question) Is it the interface it provides, the types, the coupling of methods to data, or something else?

colomon 15y ago

I'd say the advantages are: 1) Naming it vastly clarifies further data structures and interfaces. (This is shared with having a Point3D data-structure, obviously.) 2) Providing functions and operators specific to the type. At it's simplest (and possibly most compelling) it's the difference between needing to say p.x = p0.x + t * (p1.x - p0.x); p.y = p0.y + t * (p1.y - p0.y); p.z = p0.z + t * (p1.z - p0.z); and p = p0 + t * (p1 - p0); The latter is easier to type, easier to understand, and less error prone. It's a huge win, especially in more complicated expressions. Now of course, your language may allow you to define data structure-specific functions and operators. But at that point, what you've got is essentially a class, even if you call it something else. (PS Note that data hiding is completely unimportant here, and inheritance would be nothing but trouble.)

sixbrx 15y ago
I think there is no question that being able to define new types is important. I don't, however think it's clear that having to pack operations that operate on the types into the types themselves is a good idea in general. Your example is easily handled with a simple type class in Haskell e.g., and no there's it's not "essentially a class" in the OO sense, as new operations can be freely added without modifying the type itself.
- colomon 15y ago
  Er, I've never used a OO language that didn't allow you to add new operations freely without modifying a class. Not all of them allow you to add new methods, sure, but new functions and operators are par for the course. And surely you're not arguing the defining feature of a class is that it's closed?
gruseom 15y ago
I agree with you that Point3D-type-thingies are a sweet spot, though your operator-overloaded line is not doable in most class-based languages, and indeed is generally controversial in OO, so I don't think it gets to count here. That aside, you're quite right that when one has a common construct that permeates the entire program, one badly wants to give it first-class status in the language. What I've noticed, though, is that these constructs don't tend to get involved in complex object graphs (or if they do, they're leaf nodes). Rather, they tend to be atomic and universal (i.e. interoperable with anything) and simple. So I wonder if what one really wants here is the ability to add new primitives to the language. That's potentially quite different from classical classes. It's more related to the "build up a language that fits the problem, then code the solution in that language" idea.
- colomon 15y ago
  You might guess from my example how little respect I have for the "don't overload operators" argument. All I can say is, all the OO languages I've spent any time programming do indeed let you do that, and I'm sorry for you if your experience is otherwise. So clearly I agree that adding primitives is an extremely important ability. But it's already nearly if not completely there in all the OO languages I use, using classes. I don't think primitives are enough, though. The interface / implementations of interfaces combination is also essential to my programming. Being able to say "Curve" and have it mean Straight or NURBS curve or Circle or Offset curve or Composite curve or... is another huge simplifying device. In fact, I've just looked at my code, and I have 15 distinct curve types, at least 5 of which I'd have missed if you asked me to list them, despite having written all of them over the years. That is exactly the power of simplifying abstraction. Let me point out that given a sufficiently capable OO language, this doesn't need inheritance to implement. This is just the implementation of a role or interface. But it does need classes.