Object composition challenge
bruant.d at gmail.com
Sat Mar 17 11:37:12 PDT 2012
Le 17/03/2012 00:36, John J Barton a écrit :
> On Fri, Mar 16, 2012 at 4:18 PM, David Bruant <bruant.d at gmail.com> wrote:
>> This is a piece of cake with Java's protected. It is much convoluted in
>> 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
> This extract a cost in real projects.
This extracts a short-term cost, I definitely agree. This cost may be
Exposing too much has a cost as well.
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.
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".
The extracted cost is not free. It may be paid somewhere else, later,
maybe at a much higher price.
> The benefits of private/protected are exaggerated, as
> can be clearly demonstrated by admiring the success of languages
> without it.
I don't understand the correlation between private/protected and
The benefits of private and protected are what they are. They are not
absolutely necessary in a language at all, regardless of its success.
More information about the es-discuss