Re: Keyword arguments and fn:serialize [was fn:slice]

I fully agree with @Liam R. E. Quin <liam@fromoldbooks.org> that the
problems of fn:serialize() are the same as the problems of any function
that has 20+ parameters.

Still, if all 20+ arguments have good default values, then one needs to
specify in an actual function call just a few overrides and this is where
using keyword arguments (with good defaults) is really helpful.

Of course, if no set of good defaults are available, this is the result of
bad design and neither maps/records nor keyword parameters can help in such
case, as the developer will need to specify too-many arguments in each case.


On Mon, Dec 7, 2020 at 4:22 PM Liam R. E. Quin <liam@fromoldbooks.org>
wrote:

>  You can't, with the
> proposal i wrote, have both a 3-argument function and a 4-argument
> function where the 4th argument is optional and the names are the same,
> as it wouldn't be possible to tell which one to call - unless there was
> a rule to disambiguate, which is certainly possible.
>

And let me slightly correct Liam here. At first glance it seems that having
a function with m + N parameters, where the latter N are keyword
parameters, that this prohibits defining and using an overload of arity m +
k, where  1<= k < N

Fortunately this is not true!

As I pointed out in a previous message in this thread, there is no
ambiguity between:

   myFun#3(12)     (:  uses the defaults for $arg2 and $arg3   :)

and

   myFun#1(5)

And even more, in the case when the type of the argument of myFun#1 is
xs:string (not xs:integer), then we don't even need to specify the arity.
These are not ambiguous.

   myFun("Hello") cannot be mistaken for   myFun#3("Hello), because
myFun#3 requires the first argument to be of type xs:integer.

And of course, if one follows the rules of good design, they will try to
declare their new overload such that when all new keyword arguments are set
to their defaults, the resulting function has exactly the behavior of the
existing, lesser-arity function overload. In this case there would be no
need for any explicit arity-disambiguation. One would simply remove the
lesser-arity overload and use only the newly created overload.

Thus, if we have

   myFun#1($arg1 as xs:integer)

and we create:

   myFun#3($arg1 as xs:integer, $arg2 as xs:string default: "Hi", $arg3 as
xs:double default: 3.14)

and   myFun#3(?, "Hi", 3.14)  behaves exactly as  myFun#1

then we can safely remove the declaration of   myFun#1,  and just use
without any ambiguity:

  myFun($arg1)  (: myFun#3 will be called with the default values for
$arg2  and  $arg3 :)

Thanks,
Dimitre



>
> Thanks!
>
>
> --
> Liam Quin, https://www.delightfulcomputing.com/
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org
>
>
>