Re: Prollyfills and the global namespace / multi-fills

On Wed, Jul 3, 2013 at 7:58 PM, Marcos Caceres <w3c@marcosc.com> wrote:

> Generally speaking: I'm no longer going to call the things I work on
> prollyfills - going to call the things I work on something else: they are
> "prototype reference implementations" of real specifications explicitly
> meant to inform the standardization process (verify spec prose and WebIDL,
> produce/verify test suites, and allow interested people to take an API for
> a test drive) - and not necessarily to be used for anything else.
>
> I thought those were prollyfills, but turns out I was wrong - but that's a
> good thing. I personally see tremendous value in "proto-ref-imps" (oh yeah!
> that's totally gonna catch on:)) - and encourage others in also building
> them align with these prollyfill things (whatever those are).
>
> Having said that, as we've discussed, there is good practices and hygiene
> that can be applied to them: like wrapping them in such a way that, where
> possible, things like the global scope and window become
> configurable/overridable, and, as François suggested, console warnings. And
> worst case, use some kind of namespacing when possible (though I'm sure
> this will end in tears, as it always does).
>
> Responses to Tobie inline…
>
> On Wednesday, July 3, 2013 at 10:21 PM, Tobie Langel wrote:
>
> > On Wednesday, July 3, 2013 at 9:46 PM, François REMY wrote:
> > > > Ok, I can see where there could be potential clashes for
> > > > unmaintained code. But I think this would be rare.
> > >
> > >
> > >
> > > It's not rare at all. Most websites are unmaintained, and they hold
> the web
> > > platform back. Ask any implementor for stories where unmaintained
> websites
> > > slowed down the unprefixing or the introduction of new APIs because of
> > > conflicts, you'll see for yourself.
> >
> > We had serious issues back in the days with PrototypeJS for
> document.getElementsByClassName, Function.prototype.bind,
> Array.prototype.reduce, Array.prototype.indexOf, Array.prototype.toJSON,
> String.prototype.toJSON, document.querySelectorAll, etc.
> >
> > This is absolutely going to happen.
> Was the problem that you were not able to tell if all those method's
> .toString() function returned "function valueOf() { [native code] }"? Or
> that those had been hijacked even though the browser did support the real
> deal?
>
> > > > I'm just thinking there is a differentiation to be made
> > > > between a library and prollyfill (which is intended to
> > > > inform a standardization process, for instance).
> > >
> > >
> > >
> > > Prollyfills -can- inform standards bodies. But for that to be
> effecient,
> > > they have to be used on real websites. Sure it can be on demo
> websites, but
> > > as soon as it works, people will want to use it in production (why
> not?).
> >
> >
> > Yeah, these will run in prod weeks after release. And then won't be
> touched for years.
> Sure.
> >
> > >
> > > We've to make sure this prollyfilling approach does not harm the web by
> > > spreading old versions of specs on the global namespaces other scripts
> > > mistakenly take for a native implementation.
> >
> >
> > A possible approach would be to agree on a way to mark prollyfills
> (seriously who came up with _that_ term?)
> I read that "Alex Sexton coined the term “prollyfill” on Twitter" [1]…
> let's get him! :)
> > as such so that if things get awry (and they will) there's at least an
> easy way to distinguish them from native code, e.g.: have a prollyfill
> property with a version string.
>
> Sure, but we should also request this functionality from the TC39 folks
> (there a few lurking here). That is, some reliable ways to check if
> something is a host object/function or not. We have the following to check
> the native brand (or whatever it's called now) of an instance:
>
> Object.prototype.toString.apply(V)
>
> There may be other more sophisticated tricks coming in ES6 to reliably
> check if a function is natively implemented (or not). But I don't know -
> might not even be possible.
>
> [1]
> http://briankardell.wordpress.com/2012/11/17/w3c-extensible-web-community-group/
>
>
Maybe this would be a good time to define some terms? I'm a little confused
on them as well. Here are the types of libraries I've seen mentioned so far
that probably need to be differentiated:

- libraries that implement W3C standards in browser that do not yet have
this functionality (polyfills)
- libraries that implement W3C drafts that have been proprosed and not yet
standardized
- libraries that implement lower-level interfaces that allow developers to
build their own higher-level interfaces off of (possibly in draft possibly
not proposed yet) (pro-ref-imps?)
- prototypes that extend the webs functionality by using those lower level
interfaces (I'm assuming this is what a forward polyfill or prollyfill is
as mentioned in http://smus.com/how-the-web-should-work/ correct me if I'm
wrong)

The wiki might be a good place to expand upon this?
-- 
- Michael Mullins