Geir Magnusson Jr. wrote: > There's caching too, I think. LogCache4J > > What I meant was that it didn't seem like we came to a conclusion on it > - that if we had a general pre-processing solution, we could use that > too for logging, rather than have two. > > The actual use-cases will help figure this out.
Here two typical some use cases, and some proposed solutions:
Problem
-------
logging, and other situations where you really don't want to put the
"additional" source code in the main source files
Solution
--------
use aspects (Plug: you might want to give a look at the optimizing abc
compiler)
Problem
-------
supporting a different API specifications/versions, such as j2me and
j2se1.4, in addition to the "main" version (e.g. j2se1.5)
Solution
--------
This is a trickier problem. We can divide the problem at two main levels:
1- file/directory level
2- source-code level
At the file/directory level, each version (e.g. j2me, j2se1.4, ...)
might include additional files (relative to the main version), and might
not include some files of the main version. In other words, j2me might
not contain database APIs.
Managing file inclusion/exclusion can be done in various ways.
a) ant based: use distinct ant (sub-)files for each version.
The problem is that IDEs (e.g. Eclipse) will most likely show some
of the excluded files in its class/files browser. This wouldn't be
very elegant. It also implies "always" compiling through ant files.
Of course, one could develop Eclipse-specific configuration files to
mimic the inclusion/exclusion of ant files, but then, this opens the
door for discrepancies between ant vs eclipse inclusion/exclusion
lists. I don't like it.
b) custom-tool based: the custom processing tool I proposed could also
parse inclusion/exclusion lists, and use these lists to move files
around, in addition to processing the content of unmoved files.
For example, if class X of the main version is not part of j2me,
"process(j2me)" would move this file to a subdirectory ".streams/".
If a class Y is not in the "main" version (the one used for "svn
ci"), it resides in subdirectory ".streams" in the trunk.
"process(j2me)" moves this file into the normal directory.
As for IDEs, now you can configure them to automatically exclude
".stream/" directories.
Inclusion/exclusion could be managed in two ways:
1- the processing tool could look for inclusion/exclusion list files,
such as "j2me.inclusion, j2me.exclusion, main.inclusion,
main.exclusion, etc."
This would lead to the best performance (for process(X)), yet it
does require much manual update of inclusion/exclusion lists, with
all the discrepancies that result from human mistakes while
updating these files.
2- (my preferred way), directives, at the beginning of the source
code would indicate whether a file is included in a version or
not. Depending on target, the file would be moved to the
appropriate directory (normal, ".streams").
Of course, there's also the problem of non-source files, i.e.
resources. IMO, resources could be managed using specific
directories (".main/", ".j2me", ".j2se1.4") and a ".shared/"
directory with symbolic links in the specific directories.
As for source-level management, you would use my proposed processing
tool to view the source files with the right spectacles [as Tim said so
elegantly:-)]. For "development targets", it is important that:
revert(process(X, target)) => X
By "development target" I mean a target that is meant for Harmony
developers in prevision of reverting "modified code" to a format
suitable for "svn ci" (i.e. revert to "main" target).
For comfortable IDE development, one could imagine that the IDE editor
can reduce to "one-line visible" comments (or better, specially
formatted ones) so that it gives you the impression that you are really
wearing target-specific spectacles. [I know Eclipse allows for such
things already].
To release code, one would apply:
process(X, release-target) => Y
Now, it is important to understand that Y, in this case, is NOT suitable
for doing any modification as
revert(Y) => Kaboom! (The tool will simply report that it can't do it;
it won't crash.)
Yet, I think that it would be important that the processing tool leaves
"markers" in Y, so that we could also have a tool to help finding the
canonical source line of a reported bug:
revertLine(Y, L') => L (where L' is a line reported by end-developer,
and L the related line in "svn").
Markers would be short single lines comments, so the end-developer
annoyance would be kept minimal.
What do you think?
I am really offering to develop this custom tool. Just help me identify
various Harmony needs I might have missed!
Of course, this tool is not the best solution to ALL problems, yet, so
far, I think that it seems to best address the problem of supporting
various API versions.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC: http://www.sablecc.org/
signature.asc
Description: OpenPGP digital signature
