Excuse me for being a show stopper, but is this another solution looking
for a problem?
As I see the problem, it's that currently, repetitive code should be
retyped. Tools like Erwin allow for code templates to be applied quickly,
without any change on the engine. A friend mine took that approach... the
only problem was that he included a template to create indexes on PK fields
because he didn't know that IB does that task automagically, but that's
another tale.
On the other hand, we need to distinguish between NEEDED extensions and
every wild and crazy extension that you, me or someone else would want to
see as part of the engine "just in case it's needed in the future". The
former ones are candidate for implementation in the CVS tree; the latter
ones are candidate for a branch of the source code that -if implemented by a
group of people- should be offered to interested developers at no cost
according to the license (or as I interpret the license).
Would it be reasonable easier than your proposition to implement those
"context variables" whose main advocate is Dalton Calford? If a trigger is
able to tell the name of the table from a system-defined variable that
invoked it, it can pass this information to a generic procedure without hard
coding the name of the table. If a trigger is able to pass the OLD and NEW
variables as a special vector-like variable to a procedure, we have the
basic needs covered without forcing to engine to undergo a total revision of
the SP/trigger language.
Maybe I'm shortsighted, but going to an OO-IB-language would need to be
done in a complete way to be satisfactory and this is no joke nor weekend
job; it seems to me a radical change to the engine. So, starting from your
aim to turn procedures into OO code, I would claim for object creation
syntax in procedures, so you can define structures with attached code, and I
would follow asking immediately support for polimorfic UDFs and variable
parameter number UDFs as a natural extension. For me, extended UDFs would be
a way to avoid implementing functions like COALESCE as built-in inside the
engine and I always can find another reasons to push my own inventions in
the list.
One problem is that after skimming IB-Priorities, one comes to the
conclusion that there's already enough food for thought and enough
requirements for years of work.

C.

> -----Original Message-----
> From: Joseph Alba [mailto:jalba@...]
> Sent: Jueves 6 de Julio de 2000 15:19
>
> >After the instantiation, modifications to the original template do not
> affect the
> >generated code, unless there is specific operator intervention.
>
> This would be quite primitive (and dangerous). Templates/Class/Interface
> definitions should always impact the instantiated objects.
>
> I was thinking that the implementation could be done in system
> tables like:
>
> RDB$TEMPLATE
> -> RDB$TEMPLATE_ID, RDB$TEMPLATE_NAME, ...
>
> RDB$RELATION_TEMPLATE
> -> RDB$RELATION_ID, RDB$TEMPLATE_ID, ...
>
> ---
> Something very similar to ROLES.
> Or method/property lookups in object-oriented implementations.
>
> The blr code can stick with templates, compiled with templates,
>
> but each table keeps a reference to the templates that it uses.(through a
> many-to-many system table like the one above).
>
> It can also have same referential integrity rules (like you can
> require the
> table to delete the trigger template reference if the template is deleted,
> or you can require that a template cannot be deleted if some table is
> referencing it.)
>
> With a lookup (referential) implementation of template triggers, the
> simplification of trigger codes will have the same impact as
> object-oriented
> methods had on traditional structured programming. (I think).
>
> Joseph Alba
> jalba@...