On Wed, Jul 9, 2014 at 10:22 PM, Matt Oliveri <[email protected]> wrote:
> 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? > I was unclear. Foo is a class/type name. The code does the equivalent of "new foo(context).Action_bar(context)" > > 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. > Remember that the only "heaviness" this pattern is concerned with is duplicated code text and indirection, because both are a source of programmer confusion, maintenance, and bugs. It's trying to avoid a big giant array superfluously mapping each "Foo" to "Foo" and "Action_bar" to "Action_bar". In the real dynamic-reflection systems I've used this pattern in, the white-list is implied by the naming convention "Action_*", which must be required to trigger dispatch. In a hypothetical static-dispatch version the white-list could be provided by the existence of the Attribute on the class and method. For example, I'd find this a good conceptual translation of the pattern (C# ish) [WebCallable] class Foo { [WebActionMethod] public void Action_bar() ... } I would consider a giant separate array/file/method listing all dispatch options the opposite of this pattern. That separate dispatch is not a bad pattern, and it has it's place, but it's not this pattern. ....There's no repetition, since someone needs to make the object name > table anyway, and the compiler makes the reflection wrappers. > What is an "object name table". Keeping it simple, in this pattern the only occurance of the object is the classname itself (and possibly its filename). The whole point is avoiding a separate file which also has to list all dispatch-able targets.
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
