Re: [whatwg] Questions regarding Path object

Thinking more about this discussion, I had an idea for an approach that would avoid such future clashes all together:

Instead of exposing constructors, why not simply expose the methods that create them?

There already are such functions for gradients:

ctx.createRadialGradient()
ctx.createLinearGradient()

Wouldn't it have been more aligned with this existing API also to have a ctx.createPath() ?

Jürg

On Oct 18, 2013, at 21:06 , Dean Jackson <dino@apple.com> wrote:

> On 17 Oct 2013, at 9:20 am, Ian Hickson <ian@hixie.ch> wrote:
> 
>>> PS: iOS 7 is barely released, but the first bug reports are already 
>>> coming in, because the new Mobile Safari now defines Path, and clashes:
>>> 
>>> https://twitter.com/danetag/status/380636739251220480
>> 
>> Looks like this user solved the problem pretty quickly.
>> 
>> I tried to find more evidence of problems now that iOS7 is out with this, 
>> but I'm not finding much. (I did a bunch of searches on Google.) 
>> 
>> Having said that, I'm not saying there's no conflicts. If Chrome and 
>> Safari want to change to a different name, we can definitely still do 
>> that, it's early days yet. DOMPath, maybe? Or Path2D, or CanvasPath.
>> 
>> Still, on the long term it'd be sad that we can't just use Path.
> 
> FWIW, many new specifications are hitting issues like this (well…
> at least Web Animations!). It’s a pain that new classes can
> clash with existing content, but I think we have to act
> as if the future is bigger than the past and thus pick the best
> name for the job.
> 
> As someone else said, the rule of not injecting into the global
> namespace from a JS library has been known for a few years now,
> and if you’re still not doing it you’re asking for trouble.
> 
> Dean
>

Received on Monday, 4 November 2013 10:08:18 UTC