Re: Issue 81: Separating audio and video capabilities

Robin,

I only think it's worth considering once you have 5 or more types. Right 
now you have 2 and I don't foresee having more in the future. When/if 
you end up with 5 or more you could switch over from one style to 
another and deprecate the original (but again, I doubt that will ever be 
necessary).

The only advantage of taking the type as argument is that you can fire 
the same logic against audio or video devices without the method in 
question knowing whether it is operating on audio or video. I agree 
there is theoretically a value in doing that, but in practice I can't 
think of a concrete use-case. Secondly, if you go down this road, I'd 
recommend removing getCapabilities() because you can emulate that 
behavior by simply invoke:

forEach (type in types)
   doSomething(getCapabilities(type));

Gili

On 19/05/2014 11:55 AM, Robin Raymond wrote:
> Presumably it would be to allow expanded definition beyond audio/video 
> in the future without expanding the surface of the API. If this could 
> only ever be applicable to audio/video I would agree. I'm not certain 
> (yet) that is true.
>
> -Robin
>
>
>> cowwoc <mailto:cowwoc@bbs.darktech.org>
>> May 19, 2014 at 11:51 AM
>> Again, why? What is gained by this approach over using separate 
>> methods for each type?
>>
>> Gili
>>
>> On 19/05/2014 8:49 AM, Peter Thatcher wrote:
>>
>> Peter Thatcher <mailto:pthatcher@google.com>
>> May 19, 2014 at 8:49 AM
>> It can be an enum.
>>