Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [Dltk-dev] Xam/Xom - CodeGear proposal to the language independent API for querying and manipulating DLTK supported languages.

  this seems like a really good idea - i've noticed that trying to create a ModuleDeclaration by hand is somewhat difficult, especially given all the ASTNode subclasses that are available and it seems that this could help simplify other areas such as code folding, etc.

   what does the underlying implementation look like? would that now be what deals w/ the source parser, etc?

  given that i don't have a working parser for the perl implementation yet, i'm not sure this does me any good right now, but +1 regardless. :)

On 8/9/07, Andrey Platov <andrey@xxxxxxxxx> wrote:

Hi folks,

 

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.

 

Kind Regards,

Andrey

 

From: Mark Howe [mailto: Mark.Howe@xxxxxxxxxxxx]
Sent: Tuesday, March 20, 2007 6:20 AM
To: Andrey Platov; Mikhail Kalugin
Cc: Joe McGlynn; Shelby Sanders
Subject: Xam/Xom concept

 

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");
//some examples
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
romClass.addMethod(existingRomMethod, newRomMethod);

 

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,  

 Cheers Mark 

 

 


_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev





--
-jae

Back to the top