Originally reported on W3C Bugzilla ISSUE-20506 Mon, 24 Dec 2012 08:17:43 GMT
Reported by Marcos Caceres
Assigned to This bug has no owner yet - up for the taking
I'm wondering if we really need MIDIOutput and MIDinput to extend MIDIPort. It seems like a bit of overkill to have to add two more additional interfaces to the platform when all that is being added is "onmessage" and on "send()" by each interface respectively. Additionally, the "type" attribute of MIDIPort is already restricted to "input" or "output", hence it feels redundant to have a whole new interface to determine the type of an object (which is already part of the base class).
I recommend just folding MIDIPOutput and MIDIIntput back onto MIDIPort. An port of type input simply does noting when send() is invoked, and MIDIPort of type output does not receive message events.
Is there a particular use case I'm missing that is not already covered?
I'm wondering if we really need MIDIOutput and MIDinput to extend MIDIPort. It seems like a bit of overkill to have to add two more additional interfaces to the platform when all that is being added is "onmessage" and on "send()" by each interface respectively. Additionally, the "type" attribute of MIDIPort is already restricted to "input" or "output", hence it feels redundant to have a whole new interface to determine the type of an object (which is already part of the base class).
I recommend just folding MIDIPOutput and MIDIIntput back onto MIDIPort. An port of type input simply does noting when send() is invoked, and MIDIPort of type output does not receive message events.
Is there a particular use case I'm missing that is not already covered?