Re: pointerType extensibility

On Tue, Feb 19, 2013 at 8:08 AM, Brandon Wallace
<brandon.wallace@yahoo.com>wrote:

> > 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?
>

I think the only value would be in having one consistent type
identification mechanism, as opposed to two (one for the initial set of
pointer types, and some other mechanism for backwards compatible
extensibility).

As I've mentioned, I don't think this is the end of the world, so given the
debate here, I do agree that we're probably best off leaving things as is
for V1 and tackling this extensibility problem when we have a concrete
example and a larger body of code to try to be compatible with.

Rick