On 2/25/13 1:15 PM, Scott Miles wrote:
You cannot accidentally stumble into ShadowDOM. You have to actively
take that step.
Sure. We all know this. I'm not sure why this strawman keeps getting
argued.
For one thing, I suggest that most of the time, the component code is
shipping w/your application, you are not depending on some resource that
will simply be upgraded out from under you.
"your application"?
The problem is when things that are poking at the internals of the
components aren't part of "your application".
I suggest you have a look at things like Optimizely for examples of the
sort of invasive monkey-patching going on right now.
For another thing, if I decide it's necessary to monkey-patch some
third-party code that's I'm using in my application, I'm generally
pretty upset if that code is privatized. It makes that unpleasant work
much harder. I need to ship ASAP, and maintenance concerns are secondary.
Sure. Is this situation more common than browser extensions or ad
scripts that monkeypatch things?
Either way the last thing I'm going to do is wily-nily update that code
and then blame the developer that my monkey-patch broke. Yes, someone
could complain in that scenario, but they have no leg to stand on.
I'm sorry, but this is hilarious. People complain in this scenario all
the time, and whether they have a leg to stand on is simply a function
of their market penetration.
Boris says the above has been a big problem at Mozilla.
With extensions monkey-patching XBL bindings, for example, yes.
This confuses me. Do developer's not know that monkey-patching clearly private
code is
bad for their maintenance?
No, they don't. See your comments about "need to ship ASAP" above.
Most people don't even bother to think about the maintainence problems
their introduce; they just figure if anything changes they'll shout
loudly for it to unchange.
For example, a common monkeypatching technique I've seen is grabbing a
function exported by the component, calling toString on it, doing some
regexp search/replace on that string and then doing new Function() with
the result and sticking it back on the component. And people get
outraged if this breaks because the toString of the function changed in
any way.
> I don't see how this can be the library
vendor's problem
It becomes the library vendor's problem as soon as the set of things
that depend on the monkeypatching has enough market share.
I suppose there is a moral hazard argument: if we make it possible,
people will overdo it.
Indeed.
This is probably true, but IMO it's akin to
saying chefs should only use butter knives because they could cut
themselves on the sharp kind.
No, more like saying that the kind of knife the chef is using shouldn't
be forced depend on where they got their tomatoes from, so when the chef
develops RSI they can use a more ergonomic knife to cut the tomatoes.
Lastly, only a subset of possible upgrades actually are transparent, not
affecting public API or behavior. Intersect that set of updates with
monkey-patchers who can't live without the update, and you are talking
about a relatively small affected class.
Do you have actual numbers to back this up? In my experience the
affected class is actually pretty large, because monkey-patching
behavior is very common and changing the source of functions, say,
without changing their public API is not that rare either.
-Boris
