Re: Advantages of object-oriented programming

Mike Austin wrote:
Just like clockwork. But anyway, what about we stray away from oop for a
second and get your thoughts on multiple-dispatch? An example in Dylan:

define method handle-event(object,
event :: <mouse-down>,
button == #left-button)
format-out("Left mouse button pressed\n");
end;

No need whatsoever for switch statements. Need to handle a new event? Write a
new method. Override a method but call the original? Call next-method().

I really wish that Dylan had succeeded. It's a beautiful language.


In my opinion, an event manager should be treated more like a database
with a schema something like:

table: Event_Handlers
----------------
object_id // Reference to widgets, such as specific buttons
event_id // Example: "on_click", "mouse_down", etc.
event_priority // optional
event_routine // actual code or a reference

If you have thousands of these, managing them in a database would be
much much easier in my opinion because you can query and report on them
in all kinds of ways.

Now, one may properly argue that a database might be too slow for GUI
usage. I tend to disagree and point out that Visual FoxPro uses roughly
this approach and (now) has pretty good performance (it puts an OO
wrapper around it, ironically). Perhaps in 1995 it was a bit sluggish,
but Moores Law has been nice to database solutions.

Building large, navigational RAM structures is so 80's. DOM is actually
a database of sorts, just not a relational one.

It is also true that one cannot currently "compile" a database for
performance or compile-time type-checking. It may be possible to
generate code to be compiled using this technique. However, one may
lose dynamic debugging ability. I am not a fan of strong-typing anyhow.
But that is a debate orthogonal to OO more or less, because there are
dynamic OOP languages like Smalltalk.

Another advantage of a database-centric solution is that it is more
language-neutral. True, the actual event code probably has to be in a
specific language, but the framework for matching events to event code
could be indepedent of app language. Having a different GUI engine for
Java and say Python is not very logical.



Mike

-T-

.

Relevant Pages

  • Re: Three Kinds of Logical Trees
    ... that includes all code that uses the dbms api would have all such units ... a variable of type int, with an int value and invoke a method ... ... >> database would have all the data and functions it needs to address ... I have no plans to design a language, but I'm happy to learn anyway ...
    (comp.databases.theory)
  • Re: Another idea from pick goes mainstream...
    ... A relational database has nothing to do ... SQL is one of the ... is now considered THE language for any dbms implementing the relational ... Then, XML came out. ...
    (comp.databases.pick)
  • Re: If you were developing a database in Forth...
    ... database that worked well, and then Dennis Ruffer provided source code ... to do the same thing in some other language and it failed it was ... It doesn't matter if the project was a stunning success or a ... that failure was the language we invented. ...
    (comp.lang.forth)
  • Re: selecting a language
    ... > languages to write our application in, as Progress is becoming ... Progress is a 4GL language so it is very rapid development. ... database access from GUI code. ... Java has a lot of built in support for it. ...
    (comp.lang.java.programmer)
  • Re: OO vs. RDB challenge
    ... >> loans have greater risk so not all users that can approve a loan ... >> database engine for that matter)? ... >> language for somethings, ah well. ... string group) ...
    (comp.object)