Re: [whatwg] Questions regarding Path object

Regardless of good practices, I still believe that Path is too general a name for a new prototype that is introduced at this point. Option and Image come to mind, but those are from the early days. More recently, things appear to have been named a bit more specifically, often with prefixes, e.g. HTMLCanvasElement, DOMParser, XMLHttpRequest (which is wrongly named, since it's used for much more than XML), XMLSerializer, RGBColor (not just Color!), etc. Naming it simply Path feels wrong.

I am quite convinced that the Path object will remain in 2D, as you are discussing the addition of stroke expansion and boolean operations. I don't see any reasonable way to do this both in 2D and 3D in one constructor. The addition may really be the right way to go, it would allow you to add a Path3D at a later point and be consistent API wise.

We do scope the library, by the way, but offer a paper.install(window) method to make the prototypes global. So far there were no clashes, and the injection happened respectfully, meaning it wasn't overriding existing properties on window.

Now it will override existing properties in order to avoid these iOS7 issues with existing content, but we will stop encouraging people to use the library globally in such a way. 

The problem that we're facing is with code examples: These are all written in PaperScript, where the paper constructors appears to be global, as PaperScript code gets executed inside a PaperScope object.

I wish JavaScript offered a way to import values into a local scope without having to copy them one by one (and without using the dirty "with(scope) {}" trick), but that's another story.

for now I guess we'll have to tell people to do this:

function() {
    var Path = paper.Path,
        Group = paper.Group,
        ...;
    // Your Paper code here.
}();

I wanted to avoid a situation where Paper is even shadowing a global Canvas constructor when used in such a way, since it's a library built for Canvas. We can of course now rename Path to something else, but who knows that our other constructors will not face the same issue at a later point?

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 Tuesday, 29 October 2013 17:47:18 UTC