Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


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.

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.