Re: Last Call comments

Chiming in quickly before being able to provide more feedback later this week. If the spec is inadequate, developer won't use it. My understanding is that it is an alternative to existing way of doing things, right?

Benoit

On Apr 8, 2013, at 9:00, Scott González <scott.gonzalez@gmail.com> wrote:

> 
> 
> 
> On Mon, Apr 8, 2013 at 11:45 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>> 08.04.2013, 19:24, "Scott González" <scott.gonzalez@gmail.com>:
>> > On Mon, Apr 8, 2013 at 11:06 AM, Konstantinov Sergey <twirl@yandex-team.ru> wrote:
>> >> Okay, look at the hammer.js pointer code: https://github.com/EightMedia/hammer.js/blob/master/src/pointerevent.js
>> >> 55 lines of code are just redundant and is used to handle the simpliest things: the number of touches and the positions of touches. And this code will be completely broken if some other script on the page uses the capturing.
>> >
>> > I think it's unfair to point to an abstraction over several event types when that's exactly what Pointer Events is. If Hammer.js was coding over the Pointer Events API and mapping Touch Events to Pointer Events, the code would be very different.
>> 
>> This code doesn't map anything. That's just the common counting pointers problem which will be implemented by everyone.
> 
> This one file alone doesn't really show anything. This is heavily tied into an abstraction built by Hammer.js. If this were purely pointer counting code in entirety, then the code would be self-contained. It's not. It contains methods that are used by some other file in order to do the counting. There is clearly more going on than just counting pointers in that code. For example, the methods matchType() and getEvents() are clearly unnecessary in a Pointer Events only environment. The updatePointer() method wouldn't need a line to abstract around the identifier property and wouldn't need a line to return a value. The getTouchList() method can just use array.map() and cut the implementation in half. So now 55 lines is probably around 10 lines. But even that number doesn't have much meaning since this is clearly tied into other code to do the management around the events themselves.
> 
>> >
>> >> We are forcing EVERY web-developer to write such code; we (Yandex Maps API team) wrote such code too - just because such simple things are "out of scope" and "we will provide helpers in v2". Meanwhile every single js framework will be forced to write that code.
>> >
>> > Surely that's not true. Most web developers will never write such code. They will simply use someone else's code which already does this.
>> 
>> In first, there are lots of code which doesn't rely on frameworks. Cartographical APIs, the different "smooth scroll" plugins, etc.
> 
> Sure, but let's avoid obvious hyperboles. You said EVERY, I didn't say none.
> 
>> In second, any errors in this code will be repeated hundreds of times.
> 
> Are you saying that it will by copy-pastd hundreds of times and the original source won't be used? If the actual source is used, then the fix is also deployed to all sites easily.
>  
>> In third, "not so many developers need to write the same code" doesn't answer the question why we are forcing to write such code at all.
> 
> No, it doesn't. But you continue to ignore the answer which is that many developers want it.
> 
>> > Also, what's wrong with iteration? Why is it imperative that v1 contain everything?
>> 
>> Then between first and second iteration hundreds of developers will write thousands lines of code which will be thrown away at the V2 spec release.
>  
> Please stop with the hyperbole. There won't be hundreds of developers writing thousands of lines of code. All of jQuery core is only thousands of lines of code. All of hammer.js is 1,217 SLOC. So realistically, we're talking about a handful of developers writing a few hundred lines of code.
> 
>> Maybe we should answer then why to release v1 spec if it obviously lacks the mechanisms which are needed by every developer?
> 
> Because it's clearly not needed by every developer. Not even close.

Received on Monday, 8 April 2013 16:08:53 UTC