I agree with Claudio about object oriented SP's.
When I started a very large project (larger in design and scope than my current job
at distributel)
I was wishing I could create a table by inheriting structure from other tables. Now
that I a little bit
older (if not wiser), I realize that in order to create a truly OO SP language would
require a complete
rewrite of how the underlying BLR language operates. We could do it (very unstably)
with a client tool that generates the appropriate blr, combined with secondary
tables and alot of other cruft. If we want to do that, we should just drop the
SP/Trigger language and
all pitch in to buy the rights to Jim's JVM so we could include it in the engine
(Java, is a true OO language).
That would make so much of a difference to how the system operates, and create so
many incompatiblities with current schema, that it should be given a new name and
marketed/supported as a totally new product.

As it is, IB, with only a few new tweaks, would cover 99% of what people are asking
for.

regards

Dalton

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