Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #30242
| From | Scott Sauyet <scott@sauyet.com> |
|---|---|
| Newsgroups | comp.lang.javascript |
| Subject | Re: Comparing some of the ways to create objects |
| Date | 2016-04-09 16:46 +0000 |
| Organization | A noiseless patient Spider |
| Message-ID | <nebblk$6dj$1@dont-email.me> (permalink) |
| References | (4 earlier) <7vtcgb5hio1hbbtg7cg0ca1dmjkel0hv6b@4ax.com> <ne73l3$2i4$2@dont-email.me> <crgfgbd1s7r9irkgg6vbm7qt6e1e8a3ctd@4ax.com> <ne9go3$ehl$1@dont-email.me> <closures-20160409050628@ram.dialup.fu-berlin.de> |
Stefan Ram wrote: > Scott Sauyet wrote: >> But the privacy offered by these techniques, even without a keyword is >> actually much stronger than that offered by Java or C# (I don't know >> about C++.) In those languages, you can use reflection to to still get >> at the field. In Javascript closure-based privacy, it's really hidden. > > Java programs can be run with a security manager, and IIRC there is a > »suppressAccessChecks« permission that can be denied to deny access to > private fields via reflection. > (I am not sure about this, I haven't tested it today.) I'm more than six years out from regularly working with Java, so I may be a little rusty. But I believe that field is precisely the reverse: a tool to _allow_ otherwise restricted code from viewing private or protected members. That's certainly how the Javadocs seem to read. [1] > But the privacy of OOP is not meant to be a shield against malicious > attacs, it is meant to be a means to help programmers not to access a > private field inadvertently. I've always thought of it a bit differently. I picture it as a way to encapsulate internal state so that one can freely change implementation without the threat of breaking dependent code. The shenanigans allowed by the combination of Reflection and ClassLoaders means there is little protection from malicious code running in the same VM, as far as I can see. But the protection offered by encapsulation is real and very important. > And one /can/ generate closures in Java too. In the Java program > below, each of »e« and »e1« have their /own/ »closure variable« > »a[ 0 ]« (which is not a field of a class). > > [ ... details and code samples elided ... ] Yes, I was gone from Java before version 8 was released, so I haven't really played around with this all that much. But it's interesting because you answered a question a colleague and I were speculating about a few days ago, but weren't quite motivated enough to actually research. ( :-> ) We knew that Java closures used static references; so you couldn't update a counter variable stored in a closure. As I pointed that out as a somewhat-crippling handicap to one colleague, another speculated, "I wonder if you could use a container like an array and simply mutate the value stored inside." Thank you for clearing that up for us! :-) So are those closure-based values as hidden as ones in Javascript? That is, are they much more private than class members with the `private` keyword, which can still be accessed through reflection? That would be interesting to know. It doesn't change how the `private` and `protected` keywords work, but it would be interesting to know. [1]: <http://docs.oracle.com/javase/7/docs/api/java/lang/reflect/ ReflectPermission.html> -- Scott
Back to comp.lang.javascript | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-03 16:09 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-04 04:15 +0000
Re: Comparing some of the ways to create objects Stefan Weiss <krewecherl@gmail.com> - 2016-04-04 15:20 +0200
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-05 04:04 +0000
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-04 16:48 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-05 04:04 +0000
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-07 15:07 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-08 01:10 +0000
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-08 14:55 +0100
Re: Comparing some of the ways to create objects Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-04-04 22:12 +0200
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-05 09:57 +0100
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-06 16:41 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-06 23:42 +0000
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-07 16:09 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-08 02:05 +0000
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-08 15:43 +0100
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-09 00:01 +0000
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-09 16:46 +0000
Re: Comparing some of the ways to create objects Scott Sauyet <scott@sauyet.com> - 2016-04-10 16:51 +0000
Re: Comparing some of the ways to create objects Stanimir Stamenkov <s7an10@netscape.net> - 2016-05-08 17:27 +0300
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-10 11:31 +0100
Re: Comparing some of the ways to create objects John Harris <niam@jghnorth.org.uk.invalid> - 2016-04-10 11:52 +0100
csiph-web