Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

Don't we have a situation where people can simply take your source and
change it regardless (barring legal imperatives, which are orthogonal in my
view)?

Given Boris' arguments, Big Marketshare can simply always mess up his
project and blame me and it's my fault. I don't accept it.

Btw, If Big Marketshare is so powerful, why haven't we already fixed
whatever thing he is monkey patching?

Also, Optimizely, et al, doesn't simply appear at random. Again, seems like
your argument is that some developer or user may take wanton stet X to
break my stuff, and I must prevent it or it's my fault.

re: "forced depend on where they got their tomatoes from" and "You cannot
accidentally stumble into ShadowDOM"

The reason the latter keeps being mentioned is because of statements like
the former. Nobody is forcing anybody to break encapsulation. Seems to me
the demarcation is very clear.

>> And all I have to do is to check the points whee my app touches the
controls

Yes, transparent upgrades are great. No argument here. But If you had
monkey-patched your libraries, you wouldn't have this ability. You didn't,
so life is good.

>>  Can we go with options when creating Shadow dom?

My understanding is that we have this option and are only talking about
what would be the default.

Lastly, my point about upgrade statistics is only that the intersection of
the two sets is generally going to be smaller than the union of them. I
should not have qualified that difference. To be clear, the intersection I
posed included "monkey-patchers that require the update", not simply
"monkey-patchers".



On Mon, Feb 25, 2013 at 10:37 AM, Bronislav Klučka <
Bronislav.Klucka@bauglir.com> wrote:

>
> 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.
>
>