Re: Representing a "dictionary or not present" member in a dictionary return value

On Mar 6, 2014, at 7:22 AM, Boris Zbarsky wrote:

> On 3/5/14 5:37 PM, Travis Leithead wrote:
>> Is there any context for this issue? E.g., has any spec run-up against this problem?
> 
> This came up in the context of designing a face-detection API in <https://bugzilla.mozilla.org/show_bug.cgi?id=965420>.  The return value is a dictionary that uses other dictionaries to represent detected facial features (eyes, mouth, etc).  When a facial feature is not detected, it seems to make more sense to have .eyes be null or undefined than to have it be an object with NaN values for the coordinates of the eyes (or some other sentinels like undefined)...

That seems like a pretty bogus use case.  It sounds like they are using structures of dictionaries to represent what should be a fundamental abstraction of their subsystem.  In other words, a domain object.  Such objects should be designed as part of an overall domain object model for the subsystem.  For example, why should clients be expected to say face.eyes = null rather than face.hasEyes().   Why is the raw data (might it vary among implementations or over time as fact detection algorithms evolve?) being exposed in the API rather than a more behavioral interface that exposes fewer implementation details. 

WebIDL is fundamentally about describing the interfaces of domain objects like this.  It sounds to me like this api should be return an object that conforms to the Face (PossibleFace, etc?) interface not a complex dictionary structure.

Dictionaries are good for things like option arguments or multiple value return records where the actual aggregation has little or no domain significance. When you start using them in place of designing real domain object interfaces you are going off the rails. 

Allen