On 25.2.2013 19:15, Scott Miles wrote:
I agree with Tab 100% on this.
You cannot accidentally stumble into ShadowDOM. You have to actively
take that step.
Sure, someone can actively take step to access my shadow DOM, thou I
explicitly made it shadow and in next version of the control things will
break.
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.
Sure, but as a desktop programmer I cannot tell how many times over the
last decade I have upgraded my applications including 3rd party
controls... And all I have to do is to check the points whee my app
touches the controls... Not caring about the rest, because the rest
cannot be broken (well, can, under extreme circumstances)
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.
Assuming of course you can legally do that... privacy of 3rd party
control has nothing to do with monkey-patchif you have the code... sure
you cannot do that from outside of the control, but that makes no
difference (the problem with private clause is inheritance, protected is
better choice)
I suppose there is a moral hazard argument: if we make it possible,
people will overdo it. 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.
Again, do we have to go with one choice here? Either or? Can we go with
options when creating Shadow dom?
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.
Well.. yours upgrades maybe...
Scott
B.
