[
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.
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
--
-jae