Suppose we tried to merge OOP and relational so that OO proponents and relational proponents are both happy. What are the roadblocks? Is it the absense of features or extra unnecessary features that may attract alleged abuse that bother each side?
Here are some possible issues:
- Inheritance. Relationalists tend to not put much stock in hierarchies, prefering set theory to classify things. Would relationalists violently object to the inclusion of inheritance?
- Merging behavior and data. OO'ers often praise the close link because it allegedly helps group behavior with matching entities, while relationalists tend to view the relationship between them as naturally many-to-many, viewing the OO tendency of one-to-one as forced or artificial.
- ObjectIdentity. Is this a performance issue or a philosophical one?
- Accessors - Should access be limited to relational operators, or should should each entity be allowed to invent its own? Is the usage of one or the other dependent on existing implementation, or philosophy? Do OO-style accessors encourage cursor-oriented collection operations (sometimes called iterators), which are generally frowned on by relationalists?
- Meta-system: Being able to query modules, routines, and/or methods as entities is probably expected from relationalists. Would static-typing OOP proponents object to this since an active engine makes compile-time prediction more difficult?
- Is there a conflict between SetsAndPolymorphism? Can object paths be useful if a path specifier can return zero or many matches if sets are used? The "single answer problem".
You can vote on them or rank them if you wish.
Merging Oop And Relational