At 10:41 PM 15/01/2005 -0200, Adriano wrote:

>Bjoern Reimer wrote:
> >
> > Default values for params in stored procs would be really nice.
> > Think on the need to extend a stored proc with at least one
> > parameter.
> > With a default parameter you donb't need to change all old calling code!
> > Very cool idea!
> >
>FYI, FB 2 already have default parameters like in some program languages.
>I'm proposing named parameters like in VB.

Application-language specific, you mean, like in Delphi? e.g. your
prepared statements are like:

execute procedure sp(:x, :y);
select * from sp(:x, :y);

Then, at the API, the application interface translates the
language-specific named params to

execute procedure sp(?,?);
select * from sp(?,?);

Meanwhile, after the statement is prepared and before the request is passed
through the API, the application accepts values for the parameters into a
parameter object via a method, e.g. in Delphi, ParamByName().AsSomeType,
and organises them into the positional XSQLVAR fields in the right order.

Are you therefore asking for the XSQLVAR descriptor to be enhanced somehow
to accept names for the arguments and make it optional whether the
positions of the XSQLVAR fields are relevant?

If this is (something) like what you want, then it would *have* to be
totally optional. The use of named params on the application side is
exploited extensively in existing super-serious OO implementations of the
API, such as IBO. Enforcing named input arguments, where the names are
taken from the argument declarations in the SP, would be a seriously
backward breakage, IMO.

Helen