Re: [w3c/webcomponents] Generic programs can't reliably use/manipulate documents via the DOM (#640)

On 14.5.2017 18:37, Matthew Ryan wrote:
>
>     It does, the same thing as in any generic desktop app development
>
> Just because it's done elsewhere doesn't mean it's right or 
> well-justified.
>
correct, but I'll make the point below discussing documentation
>
>     the argument is not about "I§m the king of the world and I know
>     best", as it's not in other environments.
>
> Indeed, the argument is long resolved elsewhere, since the language 
> implementations have historically implemented it. This does not -- and 
> should not -- preclude us from making a better or different decision 
> here, and considering fully the implications it will have.
>
But it was discussed, for several years. And a lot of implementation 
details have been considered, there have always been opposition against 
/closed/ mode and their arguments were heard, but the decision have to 
be made and have been made.
The argument is the other way around: we have the experience, it works, 
it works exactly as it should and it's pretty much always stressed to 
use encapsulation
>
>     I can open Delphi (Object Pascal), Visual Studio (C#+.NET) and
>     thou syntax is very different, in semantics it makes no
>     difference, I can tell what is public, what is private, not
>     because being the best, but to define interface. I cannot do that
>     with open shadow DOM, which part is or is not to be messed with.
>
> In my experience, this has been a major pain point for developers when 
> dealing with under-specified components. I hope you are not talking 
> personally about being unable to tell. Clearly an open shadow DOM is 
> something separate, and should be obvious by its inconvenience that it 
> is not designed to be used casually or on a whim.
>
Of course the decision on /open///closed /should not be on the whim, 
even usage of shadow dom of any kind should not be, it should not be 
used just because we have it.
The documentation is nice thing, but the best documentation is always 
the code itself, why should I look on object, listing 
properties/fields/methods and the look into documentation to see which 
is public which is not... Why should anyone spent time writing/reading 
documentation on what is private/protected/public?
this does not even exists in DOM itself, you either can see it on object 
= you can mess with that, or you do not see it at all.

>     Who benefits from it? Every single programmer using 3rd party
>     component.
>
> How? I'm still unclear on this. Perhaps you could give me an example 
> of a 3rd party component developer changing an implementation detail 
> from public to private and it tangibly benefiting one of these 
> programmers.
>
This is not about changing, this is about getting the component and 
knowing immediately, it is about knowing, that it's pretty much always 
save to upgrade, knowing, that public is safe to mess around with, 
knowing that you can rely on that. Again, trying to integrate 2 JS/DOM 
framework is pain. Everywhere else it's seamless.
>
>     I can see usecases for open and closed.
>
> Some examples might be helpful. Why would some components require 
> complete closure of implementation details and others not?
>
I have always been proponent of /closed/ only, so I'll have to live with 
the fact, that sometimes I'll look at some component and be pretty much 
where I'm today, knowing nothing :). For me, talking about components, 
there should always be /closed/ mode: "here is an interface for this 
component, that's it", as it has been proven to work for decades 
everywhere else and with the DOM native elements and native JS objects. 
There was never any access to all in web platform. It may be convenient 
to have only some native components. But it's limiting.
/Open/ mode for me? Modules. I can see e.g. putting together a module 
for files (list control to display, buttons to add, delete, pagination) 
and use it in different places in project (files for customers, files 
for tasks, files for projects). It's self contained, as shadow dom, to 
be able to be placed anywhere without breaking the module itself, or 
module breaking surroundings, but it can freely be used.
And list control is, of course (for me) closed.
>
> How would you ensure that the right one is used for the right usecases?
>
Pretty much as with anything you code?


I get that all I write about can mean nothing to you, but again, there 
have been a loooong discussion already.



          Bronislav Klučka



-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/640#issuecomment-301341472