|Re: [Dltk-dev] Xam/Xom - CodeGear proposal to the language independent API for querying and manipulating DLTK supported languages.|
Below is proposed concept from CodeGear. Talks on this was postponed until 0.9 release, and now it's a time to recall ideas about refactoring (and code manipulation in general) support for DLTK languages. Comments and ideas are very welcome.
This email describes the concept for a two way code editing API, Xam/Xom for DLTK. To give some background I've also attached JamJom documentation from JBuilder, the equivalent API for Java. I've also attached a description of why we created Jam/Jom as background to support the reasons for considering Xam/Xom.
Xam/Xom would be the language independent API for querying and manipulating DLTK supported languages. There could be a common Xam/Xom API or it could just be the common infrastructure that the individual language API's used for most of the manipulation. The rest of this description will describe the language specific API Ram/Rom, the Ruby version of Xam/Xom.
The basic idea is to create a reasonably compact and simple API to allow querying and manipulating Ruby source files. Ram/Rom would not replace any API's or functionality already defined in DLTK, instead would be a layer built on top of the tools already available in DLTK.
Ram is the high level read only abstraction of Ruby. Ram would be a fairly thin layer since all the functionality is already in DLTK. It would just consolidate that functionality into a single API.
Ram would have a central access point per project or workspace to query for objects representing the logical model of Ruby. The housekeeping of setting up search requests, contexts etc would be hidden from the API user, other than requiring some artifact such as IDLTKProject. An example of how this would differ than what already exists, is how it could encapsulated all information about a class. For instance a class "ExampleClass", that is defined across multiple files would be represented by a single entity (say a RubyClass). "ExampleClass" would know internally where each method is actually defined (i.e. would know about it's ISourceModule). The API would be kept free of any artifacts that don't represent the languages logical model, i.e. fields, methods, super classes etc.
RamFactory factory = RamFactory.instance(project);
RamClass ramClass = factory.getRubyClass("ActiveRecord::Base");
ramClass.getMethods(); //returns all methods regardless of which source file and includes ancestors
RamMethod ramMethod = ramClass.getDeclaredMethod(String methodName); //only looks for method name that is declared directly by ramClass etc.
Rom is the detailed AST writable model of Ruby. It would be based on DLTK's ASTNode. Rom would attempt to make the majority of two way editing tasks as easy as possible, but not hinder more complicated manipulation of code.
A Rom would be instantiated from a Ram.
RomClass romClass = ramClass.getRamClass();
RomMethod romMethod = ramMethod.getRomMethod();
A Rom represents a physical artifact, i.e. a class or method in a file, has position information etc. Creating and inserting methods and fields would be easy with Rom. Every Rom would have a RomPosition that would be used when inserting or appending new Roms. For instance adding a method would be something like
RomMethod newRomMethod = RomFactory.createMethod(...) -- or maybe romClass.createMethod(..) since it has context
where the existing rom method would provide the position information required by JomClass to add the new method. The same would be true for blocks, expressions and statements.
Changes would be collected until committed. Changes would also be able to be rolled back. For instance refactorings would have a change set of Rom's and would be committed collectively. If anything failed the changes would be rolled back.
That's the basic idea,
dltk-dev mailing list
Back to the top