On Sat, Mar 17, 2012 at 11:37 AM, David Bruant <[email protected]> wrote: > Le 17/03/2012 00:36, John J Barton a écrit : >> On Fri, Mar 16, 2012 at 4:18 PM, David Bruant <[email protected]> wrote: >> ... >>> This is a piece of cake with Java's protected. It is much convoluted in >>> JavaScript. I think this kind of problem being hard to solve in >>> JavaScript is the reason why so many frameworks like Node.js make the >>> choice to expose their internals. >> I doubt this is the reason. Many JS devs recognize that >> private/protected are great for the 1% programmers who work on clearly >> defined, simple problems. Predicting what needs to be exposed and what >> does not in real problems is hard and fails. > I always feel weird when I see numbers and words like "real" on > es-discuss without an empirical study to back the assertion. Or at least > examples?
I guess I should have said: Do you have any empirical evidence to support your assertion about JS frameworks? > >> This extract a cost in real projects. > This extracts a short-term cost, I definitely agree. This cost may be > paid later. > Exposing too much has a cost as well. 'Deciding' is a short term cost paid by users of private/protected. Non-users do not pay this cost. Benefit comes in the long term, but only if another developer is prevented from using the private/protected field and only if such prevention avoids some other cost. These cascading 'if's mean the benefits are rare. Cost also come in the long term, if another developer is prevented from using the private/protected field and if such prevention avoids some benefit. Also rare, but counts against the technique. > The jetpack add-ons on Firefox have access to an "unsafeWindow" property > (which provides a direct access to the window object of the current tab > IIRC). Although it did extract a cost to ship it this way, maybe it will > be used in an add-on security breach. > If they decide to remove it later, the add-on developers who started to > rely on it will all have to pay the cost. Well you are talking about a deliberate API which is later changed. I am talking about a property that is not a deliberate API. > > A lot of libraries have exposed APIs they wish they could get rid of. > They cannot, because once it's exposed, people use it, rely on it. > Consequently, library authors pay a maintenance cost for "deprecated APIs". But private/protected cannot fix this problem. Mistakes were made, deal with it. Your argument makes me think we are not on the same wavelength. To me, private/protected are a hack to allow implementations to be reused as interfaces. If you have to mark a property as "private" then you must be expecting the property to be tantalizing some developer. You are teasing them: "oooh, see this useful property? No, you cannot have it!" If you had a proper interface, then you wouldn't need 'private' because the interface would not tease. Alan Synder has a paper along this line: Encapsulation and inheritance in object-oriented programming languages http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.36.8552 Protected is even worse, because when I inherit from a class I want to manipulate the implementation. Otherwise I would use delegation. Another way to say this: fine-grained encapsulation makes re-use hard without providing the substantial benefits of full encapsulation. But as I originally said: I'm not against private/protected, just against the idea that it's all good and will suddenly solve problems we have. jjb _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
