Le 17/03/2012 00:50, Jonas Höglund a écrit : > On Sat, 17 Mar 2012 00:18:48 +0100, David Bruant <[email protected]> > 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 [email protected] https://mail.mozilla.org/listinfo/es-discuss
