Subject | Re: [IB-Architect] Trigger Templates |
---|---|
Author | Joseph Alba |
Post date | 2000-07-07T01:04:29Z |
Dear Jim,
<CTRL><ALT>-J of Delphi.
This will be a real finger saver, for now.
Seriously though, what I'm really suggesting is an upgrade from the
structured programming style of the 70's-80's to the object-oriented style
of the new century. (And this should be pretty straight-forward, as you will
see below).
With regards to your question of what happens if the templates change, I
think the "instantiated" triggers of all tables that use this template
should reflect the change (without tree based parsing please). I think it
can easily be implemented using late-binding (lookups instead of parsing).
-----------------------
I would really hope that this community can start an object-oriented
analysis of the things involved in Interbase, so that we can see
opportunities for object-orientation, and move IB toward the object-oriented
world - which would be a very smart move Coding-wise and Marketing-wise.
If you look at it, ROLES for grant priviledges have started it, and have
shown that it is possible.
If you look at ROLES as "class definitions" for grant privildges, and USERS
having roles as instantiations, and the fact that USERS can have different
ROLES show that multiple inheritance is possible. (If you want to extend the
discussion that Roles are class definitions, consider that Roles never
log-in and never really take actual/physical part in changing/accessing the
database. It is the USERS to whom ROLES are assigned that actually exist in
the real world - so, USERS - instantiation, ROLES - class definitions.)
The same thing that has been done to ROLEs can be extended to other things
involved in IB:
Back to Object-Oriented Analysis,
The "things / classes" I find in IB are:
DOMAINS / TYPES
TABLES (indexes etc are properties I think)
TRIGGERS
PROCEDURES
ROLES (users are instantiations of roles)
These give opportunities for object-orientation.
-------------------
I remember, in the early 90's, one techique we used in Clipper (and other
non-object-oriented languages) is to use arrays to implement a semblance of
Object-orientation. Since IB can define arrays on tables, triggers,
procedures, I think Object-orientation is very possible.
Again, implementation of templates is not an early-binding one - this is why
you worry about parsing, and how changes are reflected in trigger instances
of the templates. Instead of parsing, lookups (late-binding) should be used.
Reminder: Parsing (early binding) - compile time / Lookups (late-binding -
can use arrays) - run-time.
Joseph Alba
jalba@...
> Do you think this is worth the cost of a little cutThank you very much for this. It never occured to me to use the
>and paste activity in a text editor?
<CTRL><ALT>-J of Delphi.
This will be a real finger saver, for now.
>It seems to me likely that theHaha! I know I have read this line before. It's like a cliche already.
>number of keystokes expended in the implementation would exceed the
>number of keystrokes expended over the lifetime of the feature...
Seriously though, what I'm really suggesting is an upgrade from the
structured programming style of the 70's-80's to the object-oriented style
of the new century. (And this should be pretty straight-forward, as you will
see below).
With regards to your question of what happens if the templates change, I
think the "instantiated" triggers of all tables that use this template
should reflect the change (without tree based parsing please). I think it
can easily be implemented using late-binding (lookups instead of parsing).
-----------------------
I would really hope that this community can start an object-oriented
analysis of the things involved in Interbase, so that we can see
opportunities for object-orientation, and move IB toward the object-oriented
world - which would be a very smart move Coding-wise and Marketing-wise.
If you look at it, ROLES for grant priviledges have started it, and have
shown that it is possible.
If you look at ROLES as "class definitions" for grant privildges, and USERS
having roles as instantiations, and the fact that USERS can have different
ROLES show that multiple inheritance is possible. (If you want to extend the
discussion that Roles are class definitions, consider that Roles never
log-in and never really take actual/physical part in changing/accessing the
database. It is the USERS to whom ROLES are assigned that actually exist in
the real world - so, USERS - instantiation, ROLES - class definitions.)
The same thing that has been done to ROLEs can be extended to other things
involved in IB:
Back to Object-Oriented Analysis,
The "things / classes" I find in IB are:
DOMAINS / TYPES
TABLES (indexes etc are properties I think)
TRIGGERS
PROCEDURES
ROLES (users are instantiations of roles)
These give opportunities for object-orientation.
-------------------
I remember, in the early 90's, one techique we used in Clipper (and other
non-object-oriented languages) is to use arrays to implement a semblance of
Object-orientation. Since IB can define arrays on tables, triggers,
procedures, I think Object-orientation is very possible.
Again, implementation of templates is not an early-binding one - this is why
you worry about parsing, and how changes are reflected in trigger instances
of the templates. Instead of parsing, lookups (late-binding) should be used.
Reminder: Parsing (early binding) - compile time / Lookups (late-binding -
can use arrays) - run-time.
Joseph Alba
jalba@...