kn: Add support for experimental writer api #764
Conversation
Example: ```kotlin val barcode = BarcodeReader.read(iv) ``` ```kotlin val barcode = BarcodeReader.read(iv, opts) ```
5f1be8f to
450e02e
Compare
|
I think you must give this a look as I think this is not the best practice, if you have any idea about modeling this, please tell me: |
I don't like that either. While I did not have much time to really go through the PR in detail, though. |
|
I think the current version makes more sens. |
|
|
||
| @ExperimentalWriterApi | ||
| @OptIn(ExperimentalForeignApi::class) | ||
| class BarcodeWriter : WriterOptions() { |
There was a problem hiding this comment.
Looking at this, I'd like to question the utility of the BarcodeWriter class. Why not implement the toSVG/toImage members of Barcode directly calling the c-API and completely remove this class? With the above constructor idea the usecase could then look like
val svg = Barcode("some test", BarcodeFormat.QRCode).toSVG();Could you add something like this to the README.md? I'd like to always start from the client side usability and strive for a native feeling API. See also my current .NET and Rust README.
There was a problem hiding this comment.
I believe it's best to keep the BarcodeWriter class because it serves as a logical place to apply writer options. Moreover, this aligns with Java's style, even though it may not be the most convenient approach.
Regarding the toSVG and toImage methods, they have already been implemented in the code, as seen here:
https://github.com/zxing-cpp/zxing-cpp/pull/764/files#diff-108ceccf4e8d9a00451a5f5cca9c48695f005ddcc552c009530799a244f037a1R152-R157
By providing both methods for converting the barcode, users have the flexibility to choose the one that best suits their needs and preferences.
I will add the usage of toSVG and toImage later.
There was a problem hiding this comment.
The logical place to apply the options to is WriterOptions. Given my stance that BarcodeWriter is useless here, I thought about the reason for the existence of BarcodeReader. Why not have a Barcode constructor that takes an image? The answer is, the reader returns multiple objects, which a constructor can't.
What do you mean by "Java's style"?
There was a problem hiding this comment.
Because I understand that kotlin is more suited to java styles (a bunch of controllers, managers, blabla) because it influences the style of code that comes from java, and of course, in my experience, kotlin is more suited to functional programming, so I think both options are fine.
There was a problem hiding this comment.
Hmm, so why don't we change BarcodeReader to something like ImageView.readBarcodes(opts) or sth?
Dont you think that it's wierd there's Reader but not a Writer?
There was a problem hiding this comment.
I think maybe we're influenced by the design of original ZXing java, I don't know...
This commit addresses the use of fromText and fromBytes methods for constructing objects from strings or byte arrays. The changes include: Replacing fromText and fromBytes with overloaded constructors that take either a String or ByteArray parameter directly Removing the companion object since the secondary constructors handle the different input types Improves code clarity by using language features like function overloading instead of specially named methods These updates simplify the API by leveraging Kotlin's capabilities for constructor overloading based on parameter types. It makes the code more idiomatic and readable.
|
I've checked all the comments and pushed related changes. Sorry for late responding... |
|
|
||
| @ExperimentalWriterApi | ||
| @OptIn(ExperimentalForeignApi::class) | ||
| class BarcodeWriter : WriterOptions() { |
There was a problem hiding this comment.
The logical place to apply the options to is WriterOptions. Given my stance that BarcodeWriter is useless here, I thought about the reason for the existence of BarcodeReader. Why not have a Barcode constructor that takes an image? The answer is, the reader returns multiple objects, which a constructor can't.
What do you mean by "Java's style"?
|
Thanks for your continued dedication to maintain your contributed code base. Much appreciated. |
No description provided.