Samofatov, Nickolay wrote:

>There is no problem with table methods, especially if you have many
>different programs accessing database.
>You should be able to call them in SQL, just like you access table
>fields.
>
>

Why? What problem do table methods solve? Can you give us some
examples we can bat around?

>When you have all object-oriented principles implemented in database
>existing object-oriented design and implementation methodologies become
>directly applicable for database schema. Classical object-relational
>mapping techniques become redundant because they are implemented in
>database internals.
>
>

There is a long, long history of OO guys not understanding databases and
database guys not understanding OO. For evidence of the first, just
look at the huge scrapheap of failed OO database companies. For
examples of the second, you need look only as far as the Firebird 2 code
base. Database developers have demonstrated a thorough knowledge of OO
terminology and can toss around terms like polymorphism and
encapsulation with the very best of them, but when it comes to writing a
simple class with a constructor for initialization, methods to do the
work, and a destructor to clean up, they're clueless. My guess, based
on long experience, is that Firebird developers will have quite a
different perspective on OO technology once they've learned to use it
themselves.

Going directly from principles to implementation without going through
practice usually leads to unusable system.

>Object-oriented design created using current approaches (UML, Booch
>notation, etc) maps directly into database. This is good for
>time-to-market timings and should simplify development. Business logic
>becomes nicely encapsulated in database, but at the same time data is
>accessible in relational form via SQL so reporting and other massive
>operations are easy.
>
>Without table methods mapping object methods to relational model is
>extremely cumbersome.
>
>

The point is not to map object methods to the relational model, but to
improve productivity, reliability, and performance of application
systems. Encapsulation of methods into tables makes sense only to the
degree that it addresses these goals. Designing a combination hair
dryer / lawn mower is not a goal.

Firebird applications are predominately written in Java, Delphi, and C.
Two of these are already OO languages and the third has a brother
language that can be used as an OO language. Extending database
functionality that overlaps but clashes with host language features
doesn't do anyone any good. The test of any proposed extensions will be
integration with Java and Delphi that promotes productivity,
reliability, and performance.

So lets see what you've got. Sample application code at this point if
more important than BNF.