- From: Brandon Wallace <brandon.wallace@yahoo.com>
- Date: Tue, 19 Feb 2013 08:08:34 -0800 (PST)
- To: Rick Byers <rbyers@google.com>
- Cc: François REMY <francois.remy.dev@outlook.com>, Pointer Events WG <public-pointer-events@w3.org>
> Agreed - as you say the separate bits are better in this respect. But I doubt any future device would choose to do this since the impact on compatibility would be inconsistent and hard to predict (would now depend on what order existing code checked for the previously mutually-exclusive choices).
If that is a concern, then why not keep it as a single "pointerType" property that guarantees mutually exclusive choices and is easy to work with? When a new device needs to be supported, then a new subclass of PointerEvent could be created for events coming from that device and any code that cares could check for it.
Is there value in making authors write:
if (ev instanceof TouchPointerEvent) { ... }
else if (ev instanceof StylusPointerEvent) { ... }
else ...
instead of letting them choose between:
if (ev.pointerType === TOUCH) { ... }
else if (ev.pointerType === STYLUS) { ... }
else ...
or
switch (ev.pointerType) {
case TOUCH: ...
case STYLUS: ...
}
or even:
handler = { TOUCH: ..., STYLUS: ..., ... };
(handler[ev,pointerType] || defaultHandler)(ev);
I'm also thinking of libraries like jQuery that wrap the native event object within their own custom event object. Such libraries would either need to do the instanceof tests and set their own "pointerType" property on their event object, or client code would be reduced to reaching through to the original event object:
if (ev.originalEvent instanceof TouchPointerEvent) { ... }
Is there actual value in eliminating the pointerType property in favor of multiple properties or OO inheritance to justify the additional effort for authors?
Received on Tuesday, 19 February 2013 16:09:09 UTC