Consider a version without constructors and classes

[domenic]

The FaceDetector and BarcodeDetector classes seem unwieldy compared to simple function calls, e.g. navigator.detectFaces(source, options). Why do they exist? What state do they store that is so heavyweight it needs a potentially long-lived class?

[marcoscaceres]

I tend to agree. Be nice to generalize to just:

try {
    // Just make options require that the developer include the type
    const rects = await navigator.detectShapes(src, options); 
} catch (err) {  
   // For type not supported, or hardware unavailable or whatever  
}

[yell0wd0g]

Detectors initialize (relatively) costly underlying resources that they'd like to keep between function calls, e.g. for Mac:

A CIDetector object can potentially create and hold a significant amount of resources. Where possible, reuse the same CIDetector instance.

Android has a similar situation in that the Neven detector initializes some FFT stuff. Otherwise, I'd much favour having a method (per detector) ISO a class + method.

[marcoscaceres]

Ah yeah, forgot about that... but I do wonder if the UA might be in a better position to manage the underlying detector? Like it could power it down after a certain amount of inactivity time. That could allow it to share it amongst various apps and potentially avoid misuse of it (e.g., a developer accidentally spinning it up, then shutting it down, over and over as they process images in a large library of photos).

[domenic]

Detectors initialize (relatively) costly underlying resources that they'd like to keep between function calls, e.g. for Mac:

That's a pretty good reason then. It would be good to include a note in the spec that each *Detector instance is intended to hold such costly resources.

@marcoscaceres's idea is interesting though; I wonder what your thoughts are on its feasibility. Maybe it would be a good thing as a way to avoid developer footguns or just the unavoidable cost of X tabs all using separate detectors instead of sharing one.

[yell0wd0g]

I should add a note in the Spec/Readme.md , todo (+@beaufortfrancois)

[yell0wd0g]

Tentatively closing this issue after adding notes in the Spec as to why constructors are specified.