[prev in list] [next in list] [prev in thread] [next in thread] 

List:       groovy-scm
Subject:    [groovy-scm] [jira] Commented: (GRECLIPSE-617) The problem of ASTs, transforms
From:       "Andrew Eisenberg (JIRA)" <jira () codehaus ! org>
Date:       2010-04-30 22:25:12
Message-ID: 11539835.10224.1272666312940.JavaMail.haus-jira () codehaus01 ! managed ! contegix ! com
[Download RAW message or body]


    [ http://jira.codehaus.org/browse/GRECLIPSE-617?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=219570#action_219570 \
] 

Andrew Eisenberg commented on GRECLIPSE-617:
--------------------------------------------

Here are the situations where we would like the transformed ast only:

* problem finding
* build structure
* reconciling (actually, the top two are really special cases of reconciling)
* indexing

Here are the situations where we would like the concrete ast:

* compilation
* hierarchy resolving

> The problem of ASTs, transforms and how to do code resolution, content assist, etc.
> -----------------------------------------------------------------------------------
> 
> Key: GRECLIPSE-617
> URL: http://jira.codehaus.org/browse/GRECLIPSE-617
> Project: GRECLIPSE
> Issue Type: Bug
> Reporter: Andrew Eisenberg
> Assignee: Andrew Eisenberg
> Original Estimate: 0 minutes
> Remaining Estimate: 0 minutes
> 
> Starting from the discussion in GRECLIPSE-610, this issue will describe the problem \
> of how to handle ASTs that have transforms applied to them.  The problem is that \
> some IDE operations require the untransformed AST whereas others require the \
> transformed AST.  Groovy-Eclipse caches the transformed AST after each reconcile \
> and uses that to perform most of its operations like inference, content assist, \
> underlining, and code select.  The problem is that if code blocks have been moved \
> around, we are not always able to visit everything and know where to look for \
> certain pieces of code. Here are several possibilities for fixing this:
> # Always visit all parts of the AST for every visit and rather than cut a visit \
> short after an element is found, continue visiting other (synthetic) methods just \
> in case a more appropriate AST node is found.  This can be complicated because \
> things like inferencing and code select require the existence of a containing \
> IJavaElement (ie- a code element that is in the Java model and not something that \
> is transformed).  This will drastically complicate the Inferencing visitor (and \
> other similar visitors) because we always need to map back to something in the Java \
> model even if the Groovy element has been transformed and moved to a synthetic \
> groovy method outside of the model.  However, this possibility is nice because it \
> would not add any extra processing to to reconciles and memory footprint would not \
> go up. # Instead of caching a single instance of the (transformed) AST, cache both \
> the untransformed AST and the transformed AST.  This is nice because depending on \
> the operation, we can choose to walk the appropriate AST.  However, there are 3 \
> problems here.  First, it will take extra time to create the copy.  Second, the \
> size of a GroovyCompilationUnit will essentially double.  Third, some operations \
> would require both the transformed and the untransformed AST at the same time.  It \
> will be tricky to start from one, translate an AST node from one tree to the other \
> (ie- what does equality mean between these two trees?) and then use the information \
> from one tree to populate results of the other. # Only cache the untransformed \
> tree.  If Peter is right in GRECLIPSE-610 and transforms that add declarations to \
> be called in user code are rare, then perhaps we don't need to cache the \
> transformed tree at all.  Again, some extra time would be spent to create the copy \
> of the AST, but perhaps we can be smart about it and only do a copy on write.  \
> Also, the size of GroovyCompilationUnits would not need to increase.  The downside \
> is that some very common transforms would need special handling for inferencing and \
> content assist.  One that comes to mind immediately is @Singleton.  The getInstance \
> method needs to be in content assist and it should not be underlined.  So, we would \
> need to create a special ITypeLookup and ContentAssistProvider for this. At this \
> point, I am leaning towards #3, but I can also see the benefit of #1 where we do \
> not need to special case AST Transforms that add user declarations.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: \
                http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

<hr/>
<p>
To unsubscribe from this list please visit:
</p>
<p>
    <a href="http://xircles.codehaus.org/manage_email">http://xircles.codehaus.org/manage_email</a>



[prev in list] [next in list] [prev in thread] [next in thread]