3 ms·
> Haven't things which house methods and fields together gone out of fashion? Rust's structs have methods and fields together, and that seems very much in fash
by crabmusket 4y ago
> Haven't things which house methods and fields together gone out of fashion?
Rust's structs have methods and fields together, and that seems very much in fashion!
But, I wish that using OOP constructs to model ontologies would go out of fashion faster. The examples you pose are so abstract as to have no correct answer, because the correct answer depends on the needs of the software.
Cucumber/knife could be modeled in a thousand different ways depending on whether you're making The Sims, a recipe website, or the firmware for a robot chef.
"is-a" is indeed problematic, because "is" is a linguistic construct that can have different meanings, and there's never just a single "is-a" relationship. I'd go out on a limb and say you should never need classes for Square, Rectangle, etc; just make a Polygon that is a closed collection of points, and be done with it.
But that doesn't stop OOP education (from web tutorials to university courses) from teaching students to think about ontologies first and requirements second.
These are problems with the way OOP is often used, and with the language features that encourage this kind of usage. But I don't think it's necessary to say that classes in their entirety are an antipattern.
- imtringued 4y agoYes your job is to get things done not to care about ontological purity. The problem with ontological purity is that it would need complicated features that aren't worth bothering with. Oval vs circle for example is a classic case of parameter dependent typing yet no language on this planet has objects whose type changes as it's data changes.
- astrange 4y agoDependent type systems like Idris do have that.
- valenterry 4y ago> Yes your job is to get things done not to care about ontological purity. It is part of the job since it changes how (well) things get done. > no language on this planet has objects whose type changes as it's data changes. Yes there are. You might want to look into dependently typed languages.
- crabmusket 4y ago> The problem with ontological purity is that it would need complicated features that aren't worth bothering with. I think that might be true, but I don't think that's usually the problem. I think the problem is that there is almost never one "true" ontology, there are usually multiple overlapping ontologies. And in most cases of real programs, you don't need an ontology anyway. Most programs, if they need to handle ellipses as well as circles, should simply treat everything as an ellipse. If there is a specific time you need to know if something is a circle, write a function to check that. If performance is eaten up checking for circles repeatedly, sort the data into two lists of circular ellipses and non-circular.