Re: [Libreoffice-commits] core.git: tdf#97597: attempt to add test for multithreaded input stream buffering.

On 01/18/2017 03:29 PM, Kohei Yoshida wrote:
> > On January 18, 2017 at 3:31 AM Stephan Bergmann <sbergman@redhat.com> wrote:
> > Hm, I stumbled when seeing this commit.  Those "new-style" service ctors
> > are meant to make service instantiation easier and safer compared to the
> > original create-instance-from-factory way.  While createWithArguments
> > addresses safety in the return type, it does nothing for the arguments
> > (doesn't even document what they could be).
>
> Can you elaborate on this?  Is it the lack of documentation you are concerned with (which I can gladly add), 
> or what is lacking in terms of the "safety of the arguments"?

With something like

   createWithUrlAndBuffering([in] string url, [in] boolean buffered)

the available arguments and their types would be obvious to users, and 
client code couldn't accidentally pass unknown or wrongly-typed arguments.

Something like createWithArguments may be appropriate if the set of 
arguments across calls is just too 
diverse/open-ended/extending-in-future to come up with a reasonable set 
of more tightly typed ctors.  For a one-off case like here, I just don't 
see its benefits (over using a traditional create-instance-from-factory 
approach at the one call site) outweighing its (API maintenance) costs.

> > For an apparently (at least for now) one-off usage, I'm not sure adding
> > such a ctor is too useful overall.  Maybe instead use the old
> > create-instance-from-factory way in that one place?
>
> Well, I added this because I saw value in adding such a ctor.  So, at least one person finds it 
> useful. :-)  If that's not enough of an argument for adding a new ctor, then so be it.

Yeah, API design is hard.  I don't have the crystal ball either; I'm 
just uttering my thoughts.