Re: Wormholes
Steven Simpson <ss@domain.invalid> wrote:
So, we throw in a ThreadLocal:
static ThreadLocal<Context> context = ...;
class MyAppSpecBox extends Box {
InputStream getFieldContent() {
Context ctxt = context.get();
...
}
}
We set it before invoking the hierarchy:
Box root = cache.fetch(key);
Context ctxt = new Context(...);
context.set(ctxt);
InputStream in = root.getContent();
What strikes me odd in this scenario is the coincidence of
two things:
There's *only one* specific Box-subclass, that requires
specific extra information
The code that kicks off processing of the object tree does
know about this specific need and does know how to
cater to it specifically (and the specific piece of
information is even available at that place).
That looks really bolted (or duct-taped) on.
At some point in future, such things tend to accumulate.
Then either you end up with "invoking" code, that sets up
a number of different ThreadLocal<...>s for those specific
Boxes (that may or may not actually show up in the tree),
or you still set up only one such ThreadLocal<Context>,
and a couple of specific Boxes use it.
in the former case it seems like the Box abstraction
completely missed the point.
In the latter case, it seems as if it might then turn out to
be reasonable to modify the Box baseclass to pass along the
Context directly (even if some Boxes still don't need it):
class Box {
InputStream getContent(Context ctx) {
child-loop { ... child.getContext(ctx); }
... getFieldContent(ctx);
...
}
InputStream getFieldContent(Context ctx) {
getFieldContent(); // default-impl
}
InputStream getFieldContent() {return null;}
}
subclasses that need the context would override getFieldContent(Context)
the others (like the old ones) would still just override getFieldContent().