Re: General semantics

On May 22, 1:15 am, Erwin <e.sm..._at_myonline.be> wrote:
> On 22 mei, 00:20, Nilone <rea..._at_gmail.com> wrote:
>
> > I would prefer to program in a pure relational model,
>
> That is a tall order.  The closest you can get to this ideal, as
> things are today, is Rel (and that's nowhere near industrial strength)
> and Muldis D (and that's nothing more than just a spec).  I won't even
> mention my own project, which I believe to give better results from
> the perspective of "industrial strength", but which doesn't really
> facilitate "programming in a pure relational model", as you call it.
>
> > but I must deal
> > with both OOP classes and SQL tables, so I want to understand how the
> > concepts and mechanisms fit together.
>
> As things stand today, only in extremely ugly ways.
>
> > Analyzing OOP in relational terms simply opens the way to apply
> > relational thinking in existing OOP systems.
>
> Dubious.  If you can analyze OOP in relational terms, then that means
> that you understand relational terms, and that in turn means that you
> can already "apply relational thinking" to _just any_ kind of problem.
>
> So it is not the "Analyzing OOP in relational terms" that opens up to
> "apply relational thinking in existing OOP systems".  What DOES open
> up to that is merely to "understand relational thinking".

I agree with your whole post. Still, I want to describe OOP in RM to make its limitations explicit. It raises questions I want answered, such as:

1. Why can't I query the domain of a class?
2. Why does my framework stuff numerous non-identifying attributes inside an entity class?
3. Why allow programmers to override implemented methods, when interfaces and abstract classes enforce better design principles?
4. Why encapsulate everything in containers when relations provide structure-preserving aggregation?
5. If we can have classes, i.e. set-like relations, why can't we have other kinds of relations?
6. Why do our systems still describe everything in terms of blocks of bits?