On Thu, Jul 10, 2014 at 2:26 AM, David Jeske <[email protected]> wrote:
> On Wed, Jul 9, 2014 at 10:22 PM, Matt Oliveri <[email protected]> wrote:
>> 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)"
OK. You did say that, but I wanted to check, since lowercase is
unconventional for class names. I guess since it's named after the
path.
>> 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.
> ...
> 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.
Oh, I didn't think of that. That's clever. Hackish, but clever.
> 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.
Well right, if the application programmer has to implement it. But
that is how this kind of reflection works.
Now I'm thinking this pattern seems to call for a
reflection-supporting sub-language, or at least reflection-supporting
types. Here "reflection" means dynamically looking up (public)
methods, so we could call it "method introspection". Any code that we
should be able to generically hook up to a web API (say) should use
this sub-language. The purpose of the sub-language is to explicitly
point out that sub-language objects' public methods will be exposed by
reflection, and to avoid generating introspection metadata for types
outside the sub-language.
But maybe I'm being dumb, and there's some easier way to do this in BitC.
Anyway, with sufficiently powerful metaprogramming support, the
sub-language with method introspection wouldn't have to be a built-in
feature. In principle, the introspection/dispatch metadata structure
could be implemented in regular BitC, and a code generator could
translate the sub-language into regular BitC + metadata. There are a
bunch of details that would need to be worked out.
>> ....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.
Never mind. That solution was for the case that "foo" was not a class name.
_______________________________________________
bitc-dev mailing list
[email protected]
http://www.coyotos.org/mailman/listinfo/bitc-dev
