[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [Dltk-dev] i like to have a core interface change in ISourceElementParser (add one method)
|
I mean declare the parameter as
===========================================
package org.eclipse.dltk.compiler.env;
public interface ISourceModule extends IDependent {
IPath getScriptFolder();
String getSourceContents();
IModelElement getModelElement();
}
===========================================
Traditional source modules implement this interface too.
Regards,
Alex
Johan Compagner wrote:
so drop the other method/replace it completely?
I checked that out but there are a few places (like SourceIndexer in the
else part)
where i see we dont really have a ISourceModule
can we create also for that an ISourceModule easily? (its not a simple
interface :) )
johan
On Mon, Sep 8, 2008 at 11:18 AM, Alex Panchenko <alex@xxxxxxxxx
<mailto:alex@xxxxxxxxx>> wrote:
Hi Johan,
We have discussed this issue - it would be better to change old
parseSourceModule method to the following:
void parseSourceModule(
org.eclipse.dltk.compiler.env.ISourceModule module,
ISourceModuleInfo cache);
org.eclipse.dltk.internal.core.SourceModule implements both
ISourceModule interfaces (org.eclipse.dltk.core.ISourceModule and
org.eclipse.dltk.compiler.env.ISourceModule)
The places like [Lang]CalleeProcessor could provide implementations
of the org.eclipse.dltk.compiler.env.ISourceModule.
The additional benefit of this change is that source module content
would not be retrieved when AST is already in the cache.
Regards,
Alex
Johan Compagner wrote:
Hi,
past week i was very busy with getting the js code completion
into overdrive
now i have that pretty much all working, i am still working on
tweaks and stuff (like better/full support of all the build in
stuff like string, date, number and array)
But what is working now is that we can have code completion on
pretty much anything we use including what the
IDesignTimeDOMProvider provides for completion
it is pretty much 'typed' all the way now, its very cool and
very helpful for us.
The changes are almost all in the javascript projects except one
and that is the entry point to it all:
ISourceElementParser.
void parseSourceModule(char[] contents, ISourceModuleInfo cache,
char[] filename);
ISourceElement parser has that method and that is called in in
SourceParserUtils like this:
public static void parseSourceModule(ISourceModule module,
ISourceElementParser parser) {
char[] contents;
try {
contents = module.getSourceAsCharArray();
ISourceModuleInfoCache sourceModuleInfoCache =
ModelManager
.getModelManager().getSourceModuleInfoCache();
ISourceModuleInfo mifo =
sourceModuleInfoCache.get(module);
parser.parseSourceModule(contents, mifo, module.getPath()
.toString().toCharArray());
} catch (ModelException e) {
if (DLTKCore.DEBUG) {
e.printStackTrace();
}
}
}
so the source module is already broken up there. But in the
JavaScriptElementParser i need the ISourceModule
so i added
ISourceElementParser
void parseSourceModule(ISourceModule module,
ISourceModuleInfo mifo);
and let the SourceParserUtils call that method instead of
breaking down ISourceModule before hand.
Is it ok to check this in? Other implementations can just do
what SourceParserUtils does and have a very simple
implementation that just
call the existing method by extracting the contents and the path
from tthe source module
johan
------------------------------------------------------------------------
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/dltk-dev
------------------------------------------------------------------------
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev