Re: Object composition challenge
Le 17/03/2012 00:50, Jonas Höglund a écrit : On Sat, 17 Mar 2012 00:18:48 +0100, David Bruant bruan...@gmail.com wrote: A Person knows one secret and has methods like .eat(), .walk()... There is no method in the Person interface to reveal the secret either directly or indirectly. A ComputerSavvyPerson is a Person, but has an additional .getMD5HashedSecret() method which returns the hashed secret. A StupidPerson is a person with a method .tellSecret() For example, see https://gist.github.com/2053624. I don't see what's wrong with using closures for hiding variables, when necessary. There is nothing inherently wrong, just advantages and disadvantages, like any other solution. In the solution you're proposing, the secret is provided in as an argument of Person, which makes easy to build a person and have access to the secret (as you do with the 2 subclasses). I'm not sure it is applicable in every case. I'll try to come back with a more realistic use case. Meanwhile, congratulations :-) [snip] 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 think exposing the internals is more idiomatic in JavaScript to expose the internals rather than trying to hide them, similarly to how I think it's idiomatic to assume the correct types of parameters rather than manually checking their types (in many cases at least, especially for internal functions). The word idiomatic is interesting in this discussion. ECMAScript 3 has been here for about 10 years. ECMAScipt 5 barely changed the expressiveness of the language regarding abstraction and composition (getter/setters fine-grained property control and reflection). Anyway, IE8 support means staying at ES3 level. People had to understand the language in order to write the solutions of their problems given the constraints and limitations of the language. This naturally led to a culture, to idiomatic patterns, one being exposing the internals. But the point of this mailing-list (that's purely my opinion at least) is to discuss evolutions of the language. Forms that are more expressive to solve the problems that programmers want to solve. Although I acknowledge the idiomatic patterns and the culture of the language as _it was_, I think it may be worth considering questionning how things were done in the past given the past constraints and try to do better. More accurately, patterns should be studied to understand what problems were being solved, what were the good and bad parts and trying to incorporate in the language something that solves the same problem without the downsides. A direct consequence of this way of considering language evolution is that what used to be idiomatic may not be needed anymore. The exposing all properties flows well with how prototypal inheritance works I agree to the extent that there has never been private properties in JavaScript. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object composition challenge
Le 17/03/2012 00:36, John J Barton a écrit : On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com 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? 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. 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 language success. The benefits of private and protected are what they are. They are not absolutely necessary in a language at all, regardless of its success. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object composition challenge
On Sat, Mar 17, 2012 at 11:37 AM, David Bruant bruan...@gmail.com wrote: Le 17/03/2012 00:36, John J Barton a écrit : On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com 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 es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object composition challenge (was: Using Object Literals as Classes)
On Fri, Mar 16, 2012 at 4:18 PM, David Bruant bruan...@gmail.com 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. This extract a cost in real projects. The benefits of private/protected are exaggerated, as can be clearly demonstrated by admiring the success of languages without it. I'm not saying private/protected is a bad thing, I'm only disputing your conclusion. jjb David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object composition challenge (was: Using Object Literals as Classes)
On Sat, 17 Mar 2012 00:18:48 +0100, David Bruant bruan...@gmail.com wrote: A Person knows one secret and has methods like .eat(), .walk()... There is no method in the Person interface to reveal the secret either directly or indirectly. A ComputerSavvyPerson is a Person, but has an additional .getMD5HashedSecret() method which returns the hashed secret. A StupidPerson is a person with a method .tellSecret() For example, see https://gist.github.com/2053624. I don't see what's wrong with using closures for hiding variables, when necessary. [snip] 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 think exposing the internals is more idiomatic in JavaScript to expose the internals rather than trying to hide them, similarly to how I think it's idiomatic to assume the correct types of parameters rather than manually checking their types (in many cases at least, especially for internal functions). The exposing all properties flows well with how prototypal inheritance works, but even disregarding that we also see exposed internals in other dynamic languages than JavaScript, such as Python. David Jonas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
