I'm curious to know why unit-testing is the motivation. In most cases, encapsulation should never be broken for sake of exercising a public api. Private data and methods should do their work while the public api bears the results of the complete logic set, ie. the public api should fail its tests if the private data and methods are not behaving correctly.
Rick And Dave Thomas and Andy Hunt, in their book *Pragmatic Unit Testing* [6<http://www.artima.com/suiterunner/private3.html#r6>], write: In general, you don't want to break any encapsulation for the sake of testing (or as Mom used to say, "don't expose your privates!"). Most of the time, you should be able to test a class by exercising its public methods. If there is significant functionality that is hidden behind private or protected access, that might be a warning sign that there's another class in there struggling to get out. On Sun, Oct 2, 2011 at 2:50 PM, Axel Rauschmayer <[email protected]> wrote: > Yeah, sorry half-cocked idea, badly described: Generate a unique private > property name as a pair (Class ID, property name). > > If you rely on object IDs, you don’t have to think about that at all, only > if you want to reproduce a private name somewhere else (say, in a unit test) > *without* passing the name object around. > > On Oct 2, 2011, at 19:17 , Brendan Eich wrote: > > > On Oct 2, 2011, at 5:54 PM, Axel Rauschmayer wrote: > > > >>> Still, we moved private name objects ahead, and rightly so, without > adding syntax for them. > >> > >> That makes sense, as it doesn’t preclude sugar in the future. One thing > to consider: Do private names need to be globally unique or is > unique-per-class enough? The former enables many intriguing other > applications, but it might preclude moving to a nicer syntax later on. > > > > They are objects with unique identity. Objects have identity, primitive > types do not. You can forge a string. You can't forge an object. It's a > capability. > > > > If you mean to suggest two classes C and D, each with a private name P, > where C's P === D's P, that is a very bad idea. It's a capability leak, a > channel for communicating, attacking, and subverting D from C. > > > > /be > > -- > Dr. Axel Rauschmayer > > [email protected] > twitter.com/rauschma > > home: rauschma.de > blog: 2ality.com > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
