My motivation for this email is to satisfy
FORGE-773. However, this is also related to FORGE-563 and
FORGE-424, and resolution could enable other features.
I have written a prototype:
1) an implementation of the forge java api
interfaces which delegates to java's reflection,
offering a read only perspective of java components.
2) a forge module, currently a facet, to
search for a given binary class in the project's
dependencies and returns the result wrapped in the above
delegate.
These are demonstrable in a unit test.
My dilemma now is how to integrate these
into the forge project. There are a few different
areas, but I'll start with this:
For some callers, a java class is a java
class, whether it originates as source code (from the
current forge project) or is a class from the dependency
set. For example, scaffolding primarily is a read only
operation. In this use case, it would be simpler for
these clients to have a single interface to resolve
classes because whether a class is source or binary is
not relevant to the use case.
On the other hand, there is a set of classes
in a user's project that are modifiable. In these
cases, a java class is not a java class. Forge
components might want the distinction somehow. There
ought the be some distinction of which class is
modifiable and which is not.
Naively, I took the first thinking that the
existing forge java model would be adequate. To have
separate java api for read-only and read-write java
model objects seems a fundamental addition to the java
model which requires much more effort. In absence of
such a model, I though to implement 'no-op' for those
code changing methods (e.g., Named.setName() would be
inert). I assumed that forge component that change
source code would have necessary context to know when it
is operating on a source code module, avoiding attempts
to modify a binary class.
So, I'm looking for discussion and consensus
on the above. Any thoughts?
Regards,
John