On Thu, Jul 10, 2014 at 12:36 AM, David Jeske <[email protected]> wrote: > 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.
Is "foo" a class name or a name associated with an object? > 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. If "foo" is a class name, it seems like you'd need something about as heavy as a dispatch table to white list the methods that URLs can call. If "foo" is an object name, then for a generic programming solution, we could map names to "reflectable" objects, which are elements of some reflection interface. Some compiler sugar would generate a reflection interface instance for a value, based on its type. The generated method implementations could've all been done by hand, so language protections aren't bypassed. There's no repetition, since someone needs to make the object name table anyway, and the compiler makes the reflection wrappers. > 2) "standard-language-syntax" type-constructions > ... This sounds like (compile-time) computed types. There don't seem to be any security problems there. _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
