3 ms·

I think if we called it "binding functions to data", instead of "objects" we would have a much different view of how important OOP is. There are certainly times

I think if we called it "binding functions to data", instead of "objects" we would have a much different view of how important OOP is. There are certainly times that binding functions to data can be useful, but I think if you tried to tell someone "im making a language where all functions must be bound to data" they would think you're crazy. (Even though that's basically what Java is) There are so many times you don't want to bind functions to the data they operate on, and languages that force OOP always make it painful The other thing OOP gives you is type taxonomies, but frequently those are an anti-feature. Almost every experienced developer I know thinks inheritance is usually a bad idea.

gbear605 6y ago
I think the key is the ability to have functions bind to data without functions mandatorily being bound to data.
user_0x 6y ago
Having just come out of a datastructures class, this is the view that seems the most useful to me. ADTs in general seem to be very well expressed with classes, and I think it is exactly for the reason you mentioned: they are just systems that need to be able to define the ways in which a user is allowed to interact with the data.
cy_hauser 6y ago
I'd change "binding functions to data" to "binding functions to types." The "data" is an object of a particular type. The binding to the actual data (object) can take place at compile time or run time, depending on need. IMO that makes it a bit less weird and more just shifting the position of a parameter.
- overgard 6y ago
  Well, the reason I say binding to data instead of binding to type is that runtime polymorphism on instances is one of the selling points of OOP. I think its a little overrated but that is a good reason to use OO if you need that functionality. If you're only attaching functions to a type there isn't much difference between "thing.fn(x)" vs "fn(thing, x)"

gbear605 6y ago

I think the key is the ability to have functions bind to data without functions mandatorily being bound to data.

user_0x 6y ago

Having just come out of a datastructures class, this is the view that seems the most useful to me. ADTs in general seem to be very well expressed with classes, and I think it is exactly for the reason you mentioned: they are just systems that need to be able to define the ways in which a user is allowed to interact with the data.

cy_hauser 6y ago

I'd change "binding functions to data" to "binding functions to types." The "data" is an object of a particular type. The binding to the actual data (object) can take place at compile time or run time, depending on need. IMO that makes it a bit less weird and more just shifting the position of a parameter.

overgard 6y ago
Well, the reason I say binding to data instead of binding to type is that runtime polymorphism on instances is one of the selling points of OOP. I think its a little overrated but that is a good reason to use OO if you need that functionality. If you're only attaching functions to a type there isn't much difference between "thing.fn(x)" vs "fn(thing, x)"