Helen,
I think that the original subject means that we would
*also* have named parameters. If you ever worked
with MSSQL Server, you know of this

create procedure X1
@p1 int,
@p2 int
as
go

you can call the proc as

exec X1
@p2 = 1,
@p1 = 2

or

exec X1
@p1 = 2,
@p2 = 1



or

exec X1 2,1


So using of named parameters, in conjunction with
default parameters give high mantainability (save the
DBA of a lot hassles when the time to expand the
procs without breaking calling code).

On Sun, 16 Jan 2005 14:14:44 +1100, Helen Borrie wrote:

>
>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
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>
>