Object Orientation

This forum is for anything about Rel that isn't more appropriate elsewhere.
Post Reply
L505
Posts: 7
Joined: Sun Oct 26, 2008 9:27 pm

Object Orientation

Post by L505 »

Continuing previous discussion years ago about Buttons and convenience of using OO for GUI programs, I think a Object Orientation is mostly a syntax mask for something relational going on underneath the hood that people never acknowledged.

Take for example a button in SQL:

Code: Select all

  INSERT INTO button (color) VALUES (red);
Above, we see a SQL version of a button color being set. This above is verbose and atrocious for programmers to look at. Hence the shortform:

Code: Select all

  Button.Color := red;
... in languages like delphi.

In languages like C, one would write:

Code: Select all

  Button.Color = red;
So one must look at this OO code carefully and ask, why is OO convenient? What makes it useful? why do people use it? Obviously the answer is in the clarity of the code, the lack of verbosity, and the simplicity. Compared to the INSERT INTO code, the OO code is much more to the point. The answer as to why people use OO isn't in mathematical theory (sadly), rather it's in the syntax which OO offers. OO has no sound theory behind it, it's purely a syntax game played by OO salesmen. The mathematical theory behind OO actually includes relations without people knowing it.

What does this mean, practically and positively? Well on a positive note, we can keep the syntax shortcuts, but we must teach programmers in theory what actually is happening by using relational theory, not OO snake oil. We can teach people simply that Button1.color set to red, is actually a shortform for so and so relation. The button is simply a table that is being updated or inserted.

We might have a separate table for each button.

Code: Select all

  UPDATE Button2 SET Color=red;
  UPDATE Button3 SET Color=blue;
  UPDATE Button4 SET Color=red;
However we may also have a table that describes many buttons, rather than one button in a table.

Code: Select all

  UPDATE Buttons SET Color=red WHERE id=2;
  UPDATE Buttons SET Color=blue WHERE id=3;
In a delphi program one might have an Array of Buttons so that he can perform operations on them using procedural (dangerous) code which could go out of array bounds in a loop, etc. However in typical program we don't often use arrays of buttons, we often have buttons as individual unique items, along with edit boxes, menus, etc., and that's why some see programming GUI widgets as if they were oranges, cars, stereo volume controls, etc. So object orientation is simply an analogy to real life items, but they missed putting some sound theory into it.

I'm still thinking about inheritance and what this would mean relationally, for someone that wanted to take an existing button and improve it, without modifying the old code that the original button was created from.
Dave
Site Admin
Posts: 372
Joined: Sun Nov 27, 2005 7:19 pm

Re: Object Orientation

Post by Dave »

L505 wrote:So one must look at this OO code carefully and ask, why is OO convenient? What makes it useful? why do people use it? Obviously the answer is in the clarity of the code, the lack of verbosity, and the simplicity. Compared to the INSERT INTO code, the OO code is much more to the point. The answer as to why people use OO isn't in mathematical theory (sadly), rather it's in the syntax which OO offers.
I'd argue it's not just the syntax that makes OO convenient and popular, though I'm sure it helps, but the fact that OO provides subtype polymorphism. Subtype polymorphism makes it possible to write algorithms that operate on abstract interfaces, and then -- at any time, now or in the future -- write any number of concrete implementations of those interfaces. The algorithms written to those interfaces need never change, but the possible "things" the algorithms may operate on are thus effectively infinite.

The Tutorial D / Rel type system supports subtype polymorphism and is more powerful than most OO languages because it supports multiple dispatch instead of being limited to single dispatch.
Post Reply