Hi Jochen,
Thanks for the suggestions. Replies in line...
On 12/30/2016 03:20 PM, Jochen Theodorou wrote:
Hi Ed,
I am wondering if categories would actually do what you want already without touching the AST.
Groovy Categories are actually no syntactic construct and their scope is not lexical (thread local
instead)... but maybe
Let us assume you have two Strings obj1 and obj2, then you can define a
category:
class StringCategory {
static String plus(String obj1, String obj2) { "from StringCategory $obj1
$obj2" }
}
and code like this:
use (StringCategory) {
assert "a"+"b" == "from StringCategory a b"
}
the construct supports nesting from inside out, that means the inner context wins over the outer
context and the rightmost over the leftmost.
What this does not support is an instance based context.
I don't think categories will meet my wants. Categories are a way to enhance a
specific class,
whereas I'd like to have my "contexts" deal with objects of a variety of class
types.
Assuming you still want to do something like this with more... AST
involvement...
My questions for you are,
- is an AST the way to go?
first you have to decide what you want to compile to and then we can think about how the AST for
that has to look like. So this is actually the last step. But assuming you have some kind of
handler object you could compile a+b to handler.invoke("plus",a,b)... in other words you would
replace almost any expression by a MethodCallExpression. Hint: ExpressonTransformer and helper
classes.
Hmmm, I will have a handler object - sort of - and that's the context object
itself. Well, at
least in the case of instance based contexts. For class based contexts, there
won't be
an instantiated handler, but I could still see having a static "invoke" method.
I hadn't considered the invoke approach; it is interesting. I think it would
provide some
additional flexibility that the context developer could use to add "operators"
beyond the
ones built into the Groovy parser/AST. I'll have to think about this some more.
- I'm guessing that I can do the context nesting and composing by building
on
methodMissing (with ctx2 chaining to ctx3 chaining to Ctx1 above), but
is there
a better way?
I guess the code path for categories won´t help you here, since that is kind of special treated.
You could create a special meta class and all the context methods to it, then use its mechanisms
to select an appropriate method... hint getMetaMethod, init
Just to be clear, I don't think there is anything special about the contexts -
they are
just POGOs. Their methods just happen to be focused on manipulating objects
that
fall under their scope. So, I'm not sure how creating a meta class would help.
Remember, I'm trying to get away from the semantics of associating the "plus" in
"obj1 + obj2" back to obj1 (or any potential meta class). Instead, I'm trying
to
associate the "plus" back to the surrounding context (or possibly handler as you
suggest above).
- what might I be breaking in Groovy by doing this?
that depends on how you do it.
- what help/hints can I get from the compiler vs. doing this all at
runtime?
worry about such things once you have come up with something that works ;)
Yeah, one of my problems is I think too far ahead ;). I start worrying about
what
it might take to run a marathon when I haven't even learned to walk. So I don't
even get started. Part of the this resolution is to just get off my butt and
write
some code.
