I had a second look to this:

> -----Original Message-----
> From: Joseph Alba [mailto:jalba@...]
> Sent: Viernes 7 de Julio de 2000 17:05
>
> Or, in Object-Oriented lingo,
>
> 1. Is a trigger A_PART_OF the table? Or, is it more like
> 2. The table HAS_(A) trigger.
>
> For example,
>
> 1. My Hand is A_PART_OF me. I can't lend you my hand.
> 2. I HAVE_A hammer, I can lend you my hammer.

I can't lend you my hand, but I can -with my hand- execute work on behalf
of you, I can impersonate you and make the result actions point to you.
That's called DELEGATION. To my knowledge, (CLU, but I'm not sure),
Smalltalk, Actors and Delphi implement delegation. Delphi got it from BP7
and BP got it from the Object Pascal used in Apple's operating system that
in turn got it from Smalltalk. C++ is nearer to Simula than to Smalltalk, so
it doesn't have delegation. Eiffel is a good mixture of OOPascal and C++ for
lack of better short description. Borland had to "rape" C++ (sorry for the
term) in order to implement delegation and this is the origin of the CLOSURE
construction. C++ can emulate delegation natively to certain degree by
overloading the -> operator, sometimes referred as "inteligent pointer" and
with the help of pointers to members, but Borland chose to go with a
proprietary extension.

> Or, in the more familiar terms of Delphi.
>
> 1. Is a trigger more like a specific method of the table that owns it.
> 2. Or can we have triggers that are more like INTERFACEs that tables can
> share code of.

Actually, Delphi doesn't need interfaces for its original design. All it
needs is delegation. The form is the owner of the event handler methods. The
form executes the events on behalf of the components that are tied to those
events.

To scandalize Jim: if there was some syntax to bind one trigger to more
than one table, one part of the woes would be resolved, not all of them, of
course. Some ideas:
- A trigger is created for some table T1.
- The same trigger can be bound to another table T2, provided that the field
names referenced in NEW.field and OLD.field exist in T2 and are of
compatible types with the operations being done in the trigger. The same for
binding the trigger to T3 and so on.
- The way to bind triggers to tables could be an extension to alter table,
for example
alter table tbl bind trigname ...
alter table tbl unbind trigname...
- The system table rdb$dependencies keeps track of all tables using the
trigger as it currently keeps track of each table and any triggers on it.
- When a table is dropped, for each trigger that it uses, if the reference
count for the trigger becomes zero, the trigger is dropped, otherwise it
remains because other tables are bound to it.
- A trigger can be unbound, of course. If a trigger is bound to only one
table and it's unbound, it shouldn't disappear unless it's dropped
explicitly. That would create orphans at the will of the developer for later
reuse. Conversely, if a table is destroyed with a bound trigger and such
trigger doesn't serve other tables, then the trigger disappears as it
currently happens.
- There would be an extension, maybe to the "alter database" syntax, to
allow the developer to bind procedures to the OnFirstAttachment/OnLastDetach
db-wide events and also for OnLogin and OnLogoff events.
- At the time of execution, the trigger uses the "new" and "old" system
variables according to the table that invoked it, same as the "this" pointer
is set automatically in C++.

What's the real danger of this approach is something I would want to be
notified at least slightly.

As always, implementing a change is a matter to convince some developers
and start working. If Joseph joins a team of people interested in writing
parameterized and templatized OO support for IB and he succeeds, no doubt he
will be raised to the hero category in the IB community. (One problem is I
don't know how many source code developers are ready to take on IB.) On the
other side, if the changes prove to be problematic and introduce instability
in the engine, hope that such code will remain in a separate tree until it
can be stabilized. I think that in the short or long term (months, years),
the engine can (and must) do more automated work for us no doubt, but like a
few other stupid people in this list, I want an evolutionary engine, but one
that remains stable and supports enhancements without breaking current
applications, otherwise it would be painful to start looking for alternative
RDBMS engines.
After all, I was not the one that wasted badwidth with 80 posts in Mers to
ask Dale Fuller to release IB4.0 for free and with source code. :-) :-) :-)

C.