---------- Original Message -----------
From: Jim Starkey <jas@...>

> Do you have something you'd like to propose?

------- End of Original Message -------

Yes. But you won't like it. I didn't want to tie the concept of making Firebird support user-
defined types directly to whatever type system I would prefer. That would make it far too easy to
kill the proposal immediately. Architects may agree in principle, but disagree on how far they
should take it -- I'm happy to take whatever I can get.

What would I like to see, though? Something nobody else does: nominative rather than structural
typing. Domains, as boolean functions, should simply test values for inclusion in the set, and the
set can be defined in any way the user likes. Example:

function test_for_bob(value x)
{
return ((is_int(x) && between(x, to_int('40'), to_int('70'))) || (is_text(x) && is_like(x, '%
stuff%')));
}

create domain bob as test_for_bob;
create table stuff (field_a bob);

You'd want to add:
- support for sorting via UDF results;
- support for writing aggregate UDF's;
- support for some sort of boolean testing (a bit like C's ability to see ints as booleans);
- support for passing parameters to what look like attributes -- as values could be functions.

Variables should have domains (constraints), values should just have a type tag of some sort plus
the value. This actually fixes Date & Darwen's circle/ellipse paradox. I also realize exactly what
that means in terms of efficiency, which is why I'm pretty darn sure you'll disagree. But you asked
what I proposed.

With that out of the way ... what would you be willing to deal with?

-Philip