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 <[email protected]> wrote:
> On 17 Oct 2013, at 9:20 am, Ian Hickson <[email protected]> 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
>
