>OK, I've got the distinction. But if the inheritance model solves
>the problem, why screw around with the interface model?
>
>Jim Starkey

Because with the Inheritance model, the 'semantics' of OO say that the
semantics of Inheritance is fixed (static) at compile time (at the point of
definition). So, the New/Old variable validity checking responsibility
belongs to the server/compiler/DDL software.

But with the Interface model, the semantics is dynamic at can only be
realized at the point of execution (run-time). So the New/Old variable
validity need not be done by the software before hand (no need for system
entries for attribute checking, only the table-trigger relationship is
needed) but is the responsibility of the human programmer. If in case an
error of this nature is encountered (a NEW.Variable is not contained in the
table), it is only then (at that runtime point) that it is reported.

In a way, you can say that Interface trigger is actually an execute
procedure that contain NEW.Variable, Old.Variable. You may even say,
'execute (procedure/trigger) TimeStampTrig for MyTable' with TimeStampTrig
containing New.Update_by=User; New.Update_time=...

With this distinction, and with these two triggers available, the human
designer can correctly assign the semantics of his triggers (when his
triggers are checked). If he wants everything to be checked, then he
subclasses a table that inherits that nice trigger from a base table. But if
he wants to have a mix-in trigger that can be assigned to multiple tables,
then he can declare an interface type trigger - where he knows that the
semantics is his responsibility. (The server is freed from this complicated
responsibility)

I see here that Inherited Triggers can be very complicated, as I see in your
previous posts. The CART of inheritance (including that of keys and
attributes) must be built before we can even speak of the Horse of Triggers.
(So, it can be complicated because as the requirement of OO goes, the
Inheritance semantics, being static is the responsibility of software -
server/ddl)

But Interface Triggers can be as simple as an Execute Procedure that can be
related/assigned/linked to a table. No need for semantic checking on the
part of the software, the human programmer knows that it is his call.

If we find Inherited Triggers complicated to implement because it is hard to
implement inheritance and all the baggage it carries, we can just, for now,
have interface triggers - where we all know that the semantics it contains
is our human responsibility.

[Does this mean that we're back in businessness and the FDay (freedom day)
for IB is a few days away?]

Joseph Alba
jalba@...