Hi, just a short answer..
On Jan 6, 2012, at 12:11, Mark Evenson wrote:
Would you mind writing a short Markdown document describing which direction you propose to take the CLOS/MOP subsystems? See the [Pathname extension proposal][pathname.markdown] for an example of the informal nature of such a document. Obviously, an efficient implementation of CLOS with AMOP would be the ultimate goal, but we need to plan the steps to this point.
At the moment I'm still in the early stages; my immediate subgoal is to get Pascal's mop-feature-tests to run through. This will get us to at least a complete set of symbols (we're missing some exports) and a correct class hierarchy (which is what I'm working on). After that point, I can estimate and summarize the work needed for full MOP compliance.
As you might have noticed, I'm also still in the early stages of picking up abcl's coding style etc.
Currently, you seem to be implementing things in Java that I think could plausibly cast as CLOS objects themselves, but I am unclear at where this dividing line stands exactly. Do you have a heuristic for determining things? I'd love to talk about your rationale etc.
The heuristic is "do similar things to what the rest of the code does". Some stuff needs to be in Java so it's available during the boot-up phase (constructing and setting up the standard metaobjects), most of this is done in StandardClass.java. But you're right that lots of what I'm doing in Java can be done in Lisp -- specifically, via defuns in clos.lisp. I'll rework the method-combination patch in that direction.
As for code style, as Ville mentions, adopt local code style as much as possible. By personal bias in coming from the days of connecting to hosts over 1200 baud is a 80x25 window, so I try to get it down to two space where I can get away with out, for which entirely new code (such as EqualSpecializerObject) is "fair game". I'll comment more on this in reply to Ville's points in the near future.
I first set up a .dir-locals.el file in the project root that set indentation width to 2 for Java mode, but then started editing other Java files that had indentation 4, hence my asking. Perhaps it would make sense to add such a file to svn, and source files will gradually migrate to the preferred coding style as they are being edited. :)
[...]
[Will take a bit of time to test the patches, but they look good. Stay tuned.]
Actually, EqualSpecializerObject.java and the new MethodCombinationReader.java can and should be moved into Lisp, I'll fix and resubmit soon.
Rudi