On Mon, Sep 8, 2008 at 1:20 PM, Alex Panchenko
<alex@xxxxxxxxx> wrote:
I have just added
org.eclipse.dltk.compiler.env.ISourceModule#getContentsAsCharArray() method and simple compiler.env.ISourceModule implementations
- org.eclipse.dltk.compiler.env.AbstractSourceCode
- org.eclipse.dltk.compiler.env.CompilerSourceCode
Alex
Alex Panchenko wrote:
public abstract class AbstractSourceModule extends Openable
implements ISourceModule, org.eclipse.dltk.compiler.env.ISourceModule
You just need an instanceof check.
Alex
Johan Compagner wrote:
ahh i see there are 2 ISourceModules :)
that doesnt work for me.. or i have to be able to quickly switch to the other one.
Because i need, at least currently, the core.ISourceModule because thats what the IDesignTimeDOMProvider wants to have in pretty much all his methods.
But maybe we can change that to also use that one?
Is it easy to go back and forward between those 2 interfaces?
johan
On Mon, Sep 8, 2008 at 11:35 AM, Alex Panchenko <alex@xxxxxxxxx <mailto:alex@xxxxxxxxx>> wrote:
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> <mailto: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
_javascript_ElementParser 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>
<mailto: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>
<mailto: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 <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
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
