> 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.

But note that I cannot use your hand directly. I would have to send a
message to you (the object). Whether you use your hand or your feet is your
concern, not mine. I just give you a job to do.

>That's called DELEGATION.

Exactly. Until I realized that Delphi was limited to a Delegation
implementation of OO, I was a bit confounded. Now, I think of Delphi with a
component based mindset instead of OO all the way.

> Actually, Delphi doesn't need interfaces for its original design. All it
>needs is delegation.

Delphi is limited to delegation because it does not have multiple
inheritance. Now, starting with Delphi 4 we have Interfaces, which provide
some semblance of multiple inheritance (With regards to the importance of
multiple inheritance, I can think of mix-ins - design pattern which wre
quite hard to do in Delphi before Interfaces)

>- 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...

I think question here concerns coupling. How tightly coupled should triggers
be to tables. Should triggers be so tightly coupled to tables so that they
can't be dropped without altering the table? My answer to this would be no.
In fact, triggers can be loosely coupled to tables.

A simpler syntax would be

DROP TRIGGER triggername [FROM tablename[, tablename ...]]

If the keyword FROM is present, then the trigger is not actually dropped.
Rather, it is more analogous to dropping a reference constraint.

>- 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.

No need for reference counts if triggers are loosely coupled to tables.
Then, the trigger should not care less of 0 tables are attached to it.
Because someday, a table will be created to use it. A trigger with 0 tables
referencing could continue to exist. There should be no trouble with that.

>- 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.

More like it.

>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.

The usual referential Integrity should apply.

>- 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++.

Like in Delphi, there should be an invisible "self" with triggers

> 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.

No heroes please. I am more of a believer in Deming - No individual star
performers. Instead, "Team Work", "Cooperation", "Communication".

>(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 agree. This should be in JC (Bill Karwin's version of IB next release).

> 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.

Yes. It should be like C / C++. Those who like C should be able to do C,
and those who like C++ also can.
It should be like this in Interbase. Besides, IB has such a small footprint,
and I'm sure one or two more megabytes won't hurt at this present age.

But also remember that SQL that we use now is not really the first language
of IB. It is GDML, right? So, this should hint that the internals of IB
should be ready to take in linguistic enhancements anytime, and hopefully,
easily.

Regarding stupid. I am reminded again of Socrates who said, "I know that I
do not know." That's why the Oracle at Delphi called him the wisest man on
earth. In other words, the recognition of self stupidity is the birth of
self knowledge. And I really admire people of this stupidness. And in fact,
you are wise. (By the way, thank you so much for that rdb$dbkey series.)

> 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. :-) :-) :-)

My! Was it really 80?
-----------------
I'm glad HB did not take the first post as a boorish remark. As a husband, I
frequently compliment my wife for her sexy looks, and I know she appreciates
it. (Another HB. HB=Holy Bible - That should put me in my place.)

Joseph Alba
jalba@...