Arc Forumnew | comments | leaders | submitlogin
1 point by Pauan 4771 days ago | link | parent

By the way, you mentioned the "expression problem", and I looked it up. You're right, that is more or less what we're talking about. Except that my proposal is only concerned with creating new values, because I have not seen or thought of a proposal that is fantastic at creating both values and operations...

So rather than trying to completely solve the expression problem by creating a unified system, I'm instead proposing to split it up into two parts: message passing for data, and extend for programs. This is not as elegant as a unified model, but it sure as hell is easier to do, and I don't even know if a good unified model is possible.

---

Also, see this link:

http://www.cs.utexas.edu/users/wcook/papers/OOPvsADT/CookOOP...

I believe that is relevant to the discussion. What I am proposing is message passing (PDA), what you are proposing is extend (ADT). What I'm saying is that both are in conflict with each other, and that sometimes one is better than the other (depending on the situation)...

So rather than using extend for everything (your proposal), how about using extend for some things, and message passing for other things? That is what I'm proposing: using whatever model leads to shorter, more extensible code. I'm focusing on data types because data types are the only area (that I've seen so far) that message passing is significantly better than extend.

---

A quote that I found in the above pdf:

"In 1975, John Reynolds published a paper called “User-defined data types and procedural data structures as complementary approaches to data abstraction” [39] in which he compares procedural data abstraction to user-defined data types. He argued that they are complementary, in that they each has strengths and weaknesses, and the strengths of one are generally the weaknesses of the other. In particular, he found that PDAs offer extensibility and interoperability but obstruct some optimizations. ADTs, on the other hand, facilitate certain kinds of optimizations, but are difficult to extend or get to interoperate"

I have already demonstrated that in an earlier post (http://arclanguage.org/item?id=14261) that using extend for everything leads to problems, because extend isn't a silver bullet. Using a combination between extend and message passing is best.