Hm, that would be quite a lot of changes at once 😉

Well, not in one commit, but in one release. If breaking the API is required than it is obviously better to break it once instead of 3 times, right?

As you know, I'm not a fan of having an object just for the sake of it. I prefer so-called pure functions. So I really like the design of the "ReadBarcodes function + ReaderOptions struct".

I know. I remember looking into top-level functions in Kotlin last year but after learning how they are mapped into Java (I don't remember the details) I thought this is definitively not idiomatic.

But as far as I understand it, you would want to drop this design in Java/Kotlin in favor of the "BarcodeReader class with all the options as properties" design, because it's more idiomatic there, right?

I want to drop the inconsistent mix of those two designs that is currently there: BarcodeReader object + BarcodeReader::Options class + BarcodeReader::read() functions. The change I have in mind would actually trigger only one line of change in the current demo app code:

-					readerCpp.options.apply {
+					readerCpp.apply {

My point is that this 'options' entity adds no value.

So for me, the "ReadBarcodes function + ReaderOptions struct" would still fit the bill in these languages as well. But I'm obviously biased.

I'm not against that. We can have both. But the current state is neither.

My concern is that in the long run it doesn't make much sense to offer two ways of doing the same thing, mainly because there is no significant advantage of one approach over the other 😬

Yes, but maybe the advantage would be to make people with your preferences and those with others happy at the same time ;).

Well, not in one commit, but in one release. If breaking the API is required than it is obviously better to break it once instead of 3 times, right?

Definitely, yes 👍

I know. I remember looking into top-level functions in Kotlin last year but after learning how they are mapped into Java (I don't remember the details) I thought this is definitively not idiomatic.

Well, for the JVM these top level functions end up being good old static functions 😉 And I use them all the time in Java. So I can't see anything wrong with that, but YMMV, of course.

My point is that this 'options' entity adds no value.

With the current design, with BarcodeReader being an object, there's really not much value, agreed. Perhaps only that the reader options are better delineated. But that is of course a matter of taste.

Previously, BarcodeReader was a singleton, and having a separate Options class/struct made more sense there.

Yes, but maybe the advantage would be to make people with your preferences and those with others happy at the same time ;).

Understood, and I like the ambition, of course 😉 I just think that it will become too much of a burden at some point, but of cource, I always prefer simplicity over developer convenience, but I know perfectly that isn't everyone's point of view 😉

Question for the encoding expert in the room (@gitlost): The zint API seems to imply that GS1 symbols (across all symbologies) can only ever contain "text", meaning ECI 899 can not be part of it. Can a GS1 symbol contain any ECI segment at all?

In the above outlined fluent interface design I can imagine using either of the following approaches:

• something like asGS1() flag as in the example above, but that would allow calling fromBinary()
• add a fromGS1(string) function, but that would allow setting a withECI(ECI) parameter
• providing a separate CreateGS1(BarcodeFormat) factory that would not support setting any ECI/binary data, encoding this restriction in the type instead of throwing an error if configured inconsistently.

Sorry, but I've just read this discussion, what do you think of the following fluent design?
In this way we can avoid strange 'class names' like 'Read', and it's also fluent for use.

using BarcodeFormat;
auto iv = ImageView(...);
auto barcodes = Barcode
		.from(iv)
		.with(Binarizer::FixedThreshold)
		.with(TextMode::Plain)
		.withErrors()
		.withMinLineCount(3)
		.withSymbolLimit(2)
		.skipRotate()
		.fast()
		.as(LinearCodes); // The name `as` is still up for debate
		
// std::optional<Barcode> ReadPure::from()
auto pureBarcode = Barcode.from(iv).as(Pdf417); // Different from Pdf417s?
// or this
auto pureBarcode = Barcode.from(iv).asPure(Pdf417);

Please note that Read in my above example is not a class name, but a factory function for an object of class BarcodeReader. But admittedly, from the users perspective, this is irrelevant and it looks like there is a class called Read. Your suggestion with Barcode will not work for different reasons: Barcode is a class, so from would need to be a static member function (in c++) and be called Barcode::from(...). While that would be possible, I don't like it, because the return value is a list of barcodes. Barcodes also exists but is simply a std::vector<Barcode> which can not be extended. Then there is the issue that you kind of inverted the call order without explaining what types your functions return.

My idea was to have a BarcodeReader class, which needs to be created, then configured and finally used to scan the image data. But instead of using "traditional" naming like

auto reader = BarcodeReader();
reader.setFormats(LinearCodes);
reader.setReturnErrors(true);
reader.setTryHarder(false);
auto barcodes = reader.read(iv);

use a fluent API along the lines of

auto barcodes = Read(LinearCodes).withErrors().fast().from(iv);

Note that fast() returns a BarcodeReader object, while from returns a Barcodes object.

All that said, I understand why you found the name from on it's own on a BarcodeReader class non-intuitive. It only starts to make sens if you instanciate an object and name it with a verb like auto readQRCodes = BarcodeReader(QRCode); and then use it like auto barcodes = readQRCodes.from(iv);

I agree with your opinion. I forgot that sometime we need to scan multiple barcodes. For me (maybe also for you), Read(LinearCodes) is a little strange. (It works and looks reasonable, but this design isn't commonly seen elsewhere, which may cause additional learning costs?)

And here I provide another two kind of design, hope it can inspire you or help you in any other way:

BarcodeReader.read(LinearCodes).withErrors().fast().from(iv)
// or
BarcodeReader().read(LinearCodes).withErrors().fast().from(iv)

If you have a more exact idea, please feel free to ask me to implement that for the kotlin wrapper, I will be happy to do that.