On Wed, Jul 9, 2014 at 8:19 PM, Matt Oliveri <[email protected]> wrote:
> 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. This seems very sane. > How much of what is currently done with reflection actually requires > > reflection? Rephrasing: What meta-programming patterns are useful and/or popular, and what mechanisms are required to support them (compile time metaprogramming, reflection, etc)? The two most common "reflection-ish" patterns I see use of are: 1) Application visible "direct naming" dispatch Such as dispatching an http URL (foo/bar) to a Class+Method (foo.Action_bar) name at runtime. Filename based dispatching (such as foo.php) could be considered an example of this. The benefit of using reflection rather than an explicit dispatch table is (a) avoiding the multiple maintenance of keeping a separate dispatch table in-sync with classes/methods; (b) smaller code-size by eliminating the need for the dispatch table; (c) arguably easier to follow code, by eliminating the possibility of naming indirection in the dispatch table. This same direct-naming-dispatch pattern could be implemented statically with Attributes and sufficient compile-time metaprogramming. It's very important that such an implementation *not* introduce naming-indirection, since forcing direct-naming is the goal of the pattern. 2) "standard-language-syntax" type-constructions Using familiar language-syntax functions for macro-ish type-constructions. My most common use of this is in ORMs (object to relational database mappers) such as Python django. The basic idea is that a library wants to let the user construct types via macros, such as a type to represent a database-row or a serialization object. In static languages, a similar effect is achieved by IDL-based code-generators or macro-pre-processors, such as m4, Google Protocol buffers, Apache Thrift, or even XML+XSLT. However, there are drawbacks. Using an external toolchain and syntax means it is typically (a) less-familiar syntax, (b) lacks IDE/code-completion/debugging support, (c) may complicate the build, and (d) is less portable than the language itself. It would be possible to achieve standard-language-syntax type-construction in static languages with first-class compile-time type-construction -- which is not cumbersome. Note that this may or may not be the same as compile-time macros, which often introduce anti-pattern syntax extensions or mini-DSLs. DSLs can be good, but in this case, the goal is "standard language syntax" constructions.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
