On Wed, Jul 9, 2014 at 9:36 PM, Jonathan S. Shapiro <[email protected]> wrote: > If you can bypass > them, then they ain't protections.
That's what I've been trying to say about Java's static types for the past week! OK, I actually do have a real reply: > So I think there are two kinds of reflection; > > 1. Out-of-program reflection, e.g. by a debugger. This is a case where it > may make sense not to honor encapsulation boundaries, though that actually > depends on the security model. It's a little bit like the notion of a > design-time COM interface that is used by an interface builder. > > 2. In-program reflection, in which the program is inspecting itself at run > time in a way that bypasses the language protections. If you can bypass > them, then they ain't protections. By "in-program" or "out-of-program", I'm hoping you don't mean in or out-of process. Not all in-process reflection bypasses language protections. I strongly recommend that we not use the term "reflection" going forward. Without a specific language's features to make things concrete, it's an awfully ill-defined thing. Polytypy, metaprogramming, eval functions, first class this and that, RTTI, and probably other things all fit the vague notion of reflection, but they have very different semantics. For any given use case of "reflection", I could probably pick one of those as my favorite, but what are the real design considerations? > How much of what is currently done with reflection actually requires > reflection? How much could be accomplished using only static reflection? > What kinds of things are missing as first-class concepts that would help > make reflection less necessary? > > In the limit, I'm mindful that C/C++ have zero reflection, and it really > doesn't seem to slow them down all that much. But maybe I see it that way > merely because *I* have never used it and don't perceive the lack. These are interesting questions and thoughts, but I'd like us to establish more specific terminology and goals so I can avoid stumbling through an ill-phrased response. (Also, C++ has dynamic_cast.) _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
