Proposal to encapsulate device access to a dedicated class

[Craftplacer]

• sane_get_devices
• sane_exit
• sane_open
• sane_read
• sane_close

Becomes:

• Sane
  • List<SaneDevice> getDevices
  • dispose() (exit())
• SaneDevice (open() when used)
  • start()
  • cancel()
  • read()
  • dispose() (close())

[Craftplacer]

Example code:

final sane = Sane();

final devices = await sane.getDevices(localOnly: false);

for (final device in devices) {
  print(device.name);
}

final device = devices.first;

final stream = device.read();

await for (final message in stream) {
  print(message);
}

[Craftplacer]

@Jupi007 Moving here:

I understand your viewpoint. In my opinion we aren't crossing the line or taking away what a potential cross-platform library would do or implement. In my view, we are complementing how SANE as an API functions, if there's a handle, that needs to be taken care of, that's obviously an instance/object. We wouldn't take away control over anything, but instead expose the exact same functionality but more akin to Dart's and Flutter's APIs. I would like to see implementers manage handles using composition and have our library provide a safe interface.

I still think if someone wanted complete control of every function call, this enters the territory where the developer could just implement the SANE API themselves. In a way, the purist interface you describe is already what ffigen generates.

But we can ignore this topic for now, if you'd like.

[Jupi007]

I get your point. I agree that nobody should use the low level stuff in a frontend. I really don't care about provide the exact same API as the C one :D
It is really not about cross-platform nor purist api but more about testing every single part of the code independently.
Once we have a rock solid low level api around ffi, we can move around and create a good abstraction.

I would like to see implementers manage handles using composition and have our library provide a safe interface.

I also aim this target 👍
We could only expose the oop abstraction in the public api, and keep lower level stuff protected (so we can build functional tests).