3 ms·

No, because you can absolutely abstract over data if it is encapsulated, which is the whole trick of objects, You can use a Point from any vendor, without cari

by twic 5y ago

No, because you can absolutely abstract over data if it is encapsulated, which is the whole trick of objects, You can use a Point from any vendor, without caring if it has x and y, or r and theta, or some other representation inside, as long as it correctly implements the specified interface.

jrumbut 5y ago
But very few interesting real world objects can be consistently described across different pieces of software like a Point can, which is where it ties into the article.
- Verdex 5y ago
  Yeah, very much this. Not to mention, if you want to serialize Point, then you have to know what its internals look like and what they mean. There is no data abstraction. [Okay, so when you serialize Point, you can also serialize all code that will ever do anything with point. However, we generally don't do this (partially because of security issues). But it doesn't really help that much because whatever the serialized code produces when run has to be some datatype where do understand the semantic meanings behind its internals.]
- deleted 5y ago
  [deleted]
Verdex 5y ago
This feels like what you are describing is algorithmic or type abstraction. For your example, it's something like: Given some type Point which (I guess) interacts with some type Graph you should be able to run the Plot method. Or something. And in this case, yeah you can abstract, but it's not what I'm calling "data abstraction." [Maybe my name is just not quite right.] Data abstraction would be getting some arbitrary Point object and then being able to look into the internals and do the right thing. Whether it's x and y or r and theta. Now you might say, "that's just bad programming if you do that," but the point is that often times we don't have a choice in the matter because either of the constraints of the project OR because the "do the right thing" part interacts with non-code. So for example, if you want to send your Point over the network, then you either 1) Need to know the internals, what they mean, and how they work or 2) have to send along code for the remote device to execute to handle your custom internals. Case 2 is generally not done (and presents some security issues regardless). But this isn't just a technical issue. Names are notoriously difficult because data abstraction doesn't exist. How many first, middle, and last names does someone have? Is there a canonical ordering for the names? Does someone always have a name? What do the prefixes mean? What do the postfixes mean? These questions and more all have to do with what you're trying to use the name for AND what culture the name comes from. There is nothing you can do to abstract away the problem of names. And if you try you'll just end up with a lot of messy, complex code, that breaks all the time.
short_sells_poo 5y ago
You may be missing the main point of the parent (no pun intended). Their proposition is that in reality the problem is not how you define a point, but that a "point" means different things to different people and thus cannot be abstracted. I deeply agree with this observation. There are exceptions of course, but my experience is that this holds in the general case.
ithkuil 5y ago
Are you abstracting over the data or over the behaviour?

by twic 5y ago

jrumbut 5y ago

But very few interesting real world objects can be consistently described across different pieces of software like a Point can, which is where it ties into the article.

Verdex 5y ago
Yeah, very much this. Not to mention, if you want to serialize Point, then you have to know what its internals look like and what they mean. There is no data abstraction. [Okay, so when you serialize Point, you can also serialize all code that will ever do anything with point. However, we generally don't do this (partially because of security issues). But it doesn't really help that much because whatever the serialized code produces when run has to be some datatype where do understand the semantic meanings behind its internals.]
deleted 5y ago
[deleted]

Verdex 5y ago

This feels like what you are describing is algorithmic or type abstraction. For your example, it's something like: Given some type Point which (I guess) interacts with some type Graph you should be able to run the Plot method. Or something. And in this case, yeah you can abstract, but it's not what I'm calling "data abstraction." [Maybe my name is just not quite right.] Data abstraction would be getting some arbitrary Point object and then being able to look into the internals and do the right thing. Whether it's x and y or r and theta. Now you might say, "that's just bad programming if you do that," but the point is that often times we don't have a choice in the matter because either of the constraints of the project OR because the "do the right thing" part interacts with non-code. So for example, if you want to send your Point over the network, then you either 1) Need to know the internals, what they mean, and how they work or 2) have to send along code for the remote device to execute to handle your custom internals. Case 2 is generally not done (and presents some security issues regardless). But this isn't just a technical issue. Names are notoriously difficult because data abstraction doesn't exist. How many first, middle, and last names does someone have? Is there a canonical ordering for the names? Does someone always have a name? What do the prefixes mean? What do the postfixes mean? These questions and more all have to do with what you're trying to use the name for AND what culture the name comes from. There is nothing you can do to abstract away the problem of names. And if you try you'll just end up with a lot of messy, complex code, that breaks all the time.

short_sells_poo 5y ago

You may be missing the main point of the parent (no pun intended). Their proposition is that in reality the problem is not how you define a point, but that a "point" means different things to different people and thus cannot be abstracted. I deeply agree with this observation. There are exceptions of course, but my experience is that this holds in the general case.

ithkuil 5y ago

Are you abstracting over the data or over the behaviour?